Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
Hi Phil, The change looks fine. Jennifer On 10/27/2014 02:49 PM, Phil Race wrote: I can add othervm but each VM invocation slows down the overall testing time and I'd like to think this only will be run on versions that do not have the bug. I added the custom time out code so that I was not reliant on the harness to test. Certainly I can delete all of that and just go to @run main/othervm/timeout=60 60 up from 15 because it needs to include othervm overhead and avoid/minimise spurious failures See http://cr.openjdk.java.net/~prr/8028539.1/ -phil. On 10/27/2014 2:10 PM, Jim Graham wrote: The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
Hi, Jim, Phil. I just look at this code and have a related question. Why we cannot clip source coordinates(using invers transform)? This: - solve this issue - speedup all our general loops, which are based on intermediate buffers(including renderImageXform()) - we can return earlier if a clipsrc will be empty, this is important in case of single thread rendering. On 28.10.2014 1:02, Jim Graham wrote: That looks good. You bring up good points as well. The main thing I was worried about is hanging an automated regression test run if there is ever a regression... ...jim On 10/27/14 2:49 PM, Phil Race wrote: I can add othervm but each VM invocation slows down the overall testing time and I'd like to think this only will be run on versions that do not have the bug. I added the custom time out code so that I was not reliant on the harness to test. Certainly I can delete all of that and just go to @run main/othervm/timeout=60 60 up from 15 because it needs to include othervm overhead and avoid/minimise spurious failures See http://cr.openjdk.java.net/~prr/8028539.1/ -phil. On 10/27/2014 2:10 PM, Jim Graham wrote: The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
I can add othervm but each VM invocation slows down the overall testing time and I'd like to think this only will be run on versions that do not have the bug. I added the custom time out code so that I was not reliant on the harness to test. Certainly I can delete all of that and just go to @run main/othervm/timeout=60 60 up from 15 because it needs to include othervm overhead and avoid/minimise spurious failures See http://cr.openjdk.java.net/~prr/8028539.1/ -phil. On 10/27/2014 2:10 PM, Jim Graham wrote: The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
That looks good. You bring up good points as well. The main thing I was worried about is hanging an automated regression test run if there is ever a regression... ...jim On 10/27/14 2:49 PM, Phil Race wrote: I can add othervm but each VM invocation slows down the overall testing time and I'd like to think this only will be run on versions that do not have the bug. I added the custom time out code so that I was not reliant on the harness to test. Certainly I can delete all of that and just go to @run main/othervm/timeout=60 60 up from 15 because it needs to include othervm overhead and avoid/minimise spurious failures See http://cr.openjdk.java.net/~prr/8028539.1/ -phil. On 10/27/2014 2:10 PM, Jim Graham wrote: The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
