Looks good for me. Best Regards, Alexey
> On 27 May 2016, at 22:36, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > On 27.05.16 22:17, Phil Race wrote: >> I suppose this will pass on the various platforms and pipelines since >> we've only seen the bug reported against xrender ? .... > > Long time ago we had the similar issues on other platforms: > https://bugs.openjdk.java.net/browse/JDK-7112642 > > So I assume that it should not fail on all configurations(tested > ogl/xrender+linux/osx). But I intentionally added more draw operations and > didn't restrict the test on Xrender pipeline, on each platform default will > be selected and tested. > >> >> 41 * @bug 8158072 >> >> I think you should also include 7172749 on this line. > > updated: > http://cr.openjdk.java.net/~serb/8158072/webrev.01 > >> On 05/27/2016 11:47 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the new test for jdk9. >>> To me the reason of JDK-7172749 [1] falling was curious. So I decided >>> to dig into it. >>> >>> To reproduce the bug the next sequence is necessary: >>> Thread A >>> - create the surface >>> - SG2D is created for the surface >>> - SG2D.drawLine is called >>> - XRRenderer(Pipe).drawLine is called >>> - ========= STOP "THREAD A" for a nanoseconds========= >>> >>> Thread B >>> - SG2D is created for the surface create in Thread A >>> - SG2D.drawLine is called or any other draw operations. >>> - The surface is flushed. >>> >>> Thread A >>> - ========= RUN "THREAD A" again========= >>> - (we still inside XRRenderer(Pipe).drawLine) >>> - SG2D.getCompClip() is called, and this caused revalidation of SG2D, >>> because it was already flushed. This means that the surface/pipes etc >>> are changed, but note we still in the old XRRenderer(PixelDrawPipe) >>> which actually should be disposed as well >>> - we try to use the new surface and got ClassCastException. >>> - After the fix we will start to draw the line again from >>> "SG2D.drawLine" above, using new surface and the new PixelDrawPipe. >>> >>> The interesting thing is how we will work if revalidation will replace >>> the surface to the same type(so ClassCastException will not occurred) >>> but the pipe will be changed to the new? I cannot prove it but it >>> seems that we will draw something to the new surface using the old >>> PixelDrawPipe. (But this is only for the record if someone will work >>> on this/or similar issues). >>> >>> And the test which reproduce the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158072 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8158072/webrev.00 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-7172749 >>> >> > > > -- > Best regards, Sergey.