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