Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message

Krystal Mo krystal.mo at oracle.com
Fri Nov 30 19:25:32 UTC 2012


The open bug URL is: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004066

Sorry for the noise.

- Kris

On 12/01/2012 02:56 AM, Krystal Mo wrote:
> Forgot to mention: the two runs of the test in the last mail were 
> examples of test failures before the fix. They would run fine after 
> the fix.
>
> - Kris
>
> On 12/01/2012 02:48 AM, Krystal Mo wrote:
>> Hi all,
>>
>> Could I get a couple of review for this small change, please?
>> And could someone from the JDK side sponsor this change?
>>
>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066
>> Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/
>>
>> The DivModTest introduced in JDK-6282196 [1] checks the contents of 
>> the exception message, but that message isn't specified in JavaDoc 
>> and thus may vary between VM implementations (or even in the same VM).
>>
>> The issue has affected HotSpot Server VM in nightlies, and the Shark 
>> VM. As OpenJDK library code may receive broader adoption in the 
>> future, this issue may affect other VM implementations in the future 
>> as well.
>>
>> (Details:
>> The HotSpot Server Compiler may recompile hot throw sites to throw a 
>> preallocated exception object, with null exception message, leading 
>> to a NPE in the test;
>> The bytecode interpreter in Zero/Shark VM throws the 
>> ArithmeticException with "/ by long zero" for ldiv, which is 
>> different from normal HotSpot behavior (which is expected by the 
>> test) where the exception message is "/ by zero".)
>>
>> This change relaxes the test so that it's more lenient and less 
>> sensitive to the error message produced by the VM.
>> I don't think there's a good/reliable way of verifying whether an 
>> ArithmeticException came from "division by zero", checking the type 
>> should be enough for now.
>>
>> Tested with the failing nightly test case and jprt.
>>
>> $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 
>> -XX:-TieredCompilation -XX:CompileThreshold=100 
>> -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions 
>> -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions 
>> -XX:-UseCompressedOops DivModTests
>> java version "1.8.0-ea"
>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, 
>> compiled mode)
>>
>> Exception in thread "main" java.lang.NullPointerException
>>     at DivModTests.resultEquals(DivModTests.java:390)
>>     at DivModTests.testIntFloorMod(DivModTests.java:126)
>>     at DivModTests.testIntFloorDivMod(DivModTests.java:103)
>>     at DivModTests.testIntFloorDivMod(DivModTests.java:68)
>>     at DivModTests.main(DivModTests.java:45)
>>
>>
>> Description from the bug report:
>> ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests
>> java version "1.8.0-ea"
>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65)
>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode)
>>
>> FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by 
>> long zero; expected java.lang.ArithmeticException: / by zero
>> FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: 
>> / by long zero; expected java.lang.ArithmeticException: / by zero
>> FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by 
>> long zero; expected java.lang.ArithmeticException: / by zero
>> FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: 
>> / by long zero; expected java.lang.ArithmeticException: / by zero
>> Exception in thread "main" java.lang.RuntimeException: 4 errors found 
>> in DivMod methods.
>> at DivModTests.main(DivModTests.java:49)
>>
>> Regards,
>> Kris
>>
>> [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196
>




More information about the core-libs-dev mailing list