JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG
This follows from the last two paragraphs of this message: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022736.htm... The issue is https://bugs.openjdk.java.net/browse/JDK-8027595. The change is to change "@ test" to "@test" in the affected test files test/java/math/BigInteger/BitLengthOverflow.java test/java/math/BigInteger/DivisionOverflow.java test/java/math/BigInteger/DoubleValueOverflow.java test/java/math/BigInteger/StringConstructorOverflow.java for example /* - * @ test + * @test in all cases. Thanks, Brian
Hi Brian, Can you determine the minimum maximum memory needed to run these tests? Thanks, -Joe On 12/26/2013 2:35 PM, Brian Burkhalter wrote:
This follows from the last two paragraphs of this message:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022736.htm...
The issue is https://bugs.openjdk.java.net/browse/JDK-8027595.
The change is to change "@ test" to "@test" in the affected test files
test/java/math/BigInteger/BitLengthOverflow.java test/java/math/BigInteger/DivisionOverflow.java test/java/math/BigInteger/DoubleValueOverflow.java test/java/math/BigInteger/StringConstructorOverflow.java
for example
/* - * @ test + * @test
in all cases.
Thanks,
Brian
Hi Joe, I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command: jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger Brian On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
Can you determine the minimum maximum memory needed to run these tests?
The largest memory requirement among the tests in question is by the test DivisionOverflow which appears to require at least approximately -Xmx1175m to avoid an OutOfMemoryError. Brian On Dec 26, 2013, at 3:05 PM, Brian Burkhalter wrote:
I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:
jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger
On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
Can you determine the minimum maximum memory needed to run these tests?
I believe Alan knows the memory requirement that are currently called out separately in some tests; I think we should know how -Xmx1175m compares to those numbers before these test changes go back. -Joe On 12/26/2013 04:18 PM, Brian Burkhalter wrote:
The largest memory requirement among the tests in question is by the test DivisionOverflow which appears to require at least approximately -Xmx1175m to avoid an OutOfMemoryError.
Brian
On Dec 26, 2013, at 3:05 PM, Brian Burkhalter wrote:
I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:
jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger
On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
Can you determine the minimum maximum memory needed to run these tests?
Sounds reasonable. There was previously mention of this getting in before b01 so I wanted to resurface it now. Brian On Dec 26, 2013, at 4:30 PM, Joe Darcy wrote:
I believe Alan knows the memory requirement that are currently called out separately in some tests; I think we should know how -Xmx1175m compares to those numbers before these test changes go back.
-Joe
On 12/26/2013 04:18 PM, Brian Burkhalter wrote:
The largest memory requirement among the tests in question is by the test DivisionOverflow which appears to require at least approximately -Xmx1175m to avoid an OutOfMemoryError.
Brian
On Dec 26, 2013, at 3:05 PM, Brian Burkhalter wrote:
I can check it out. For comparison these run with the default settings on my 8GB RAM MacBookPro5,3 with this command:
jtreg -s -w:/tmp -r:/tmp -va -dir:$TL9/jdk/test java/math/BigInteger
On Dec 26, 2013, at 2:50 PM, Joe Darcy wrote:
Can you determine the minimum maximum memory needed to run these tests?
On 27/12/2013 00:34, Brian Burkhalter wrote:
Sounds reasonable. There was previously mention of this getting in before b01 so I wanted to resurface it now.
Brian
I see Joe's mail asking me to comment but I don't think I have much to add except that when running in agentvm mode + concurrency then it "normal" to limit the heap of the agent VMs to avoid over committing memory. For example, in jdk/test/Makefile then you'll see that the tests are run with -vmoption:-Xmx512m. One idea would be add an @run so that they run in othervm mode. That way there wouldn't be any question about whether the OOME would cause side effects that would impact tests that run subsequently in the same (agent) VM. Another idea is to just check the heap size in the test so that it skips when the heap size is too small (this approach might be a faster than attempting to test and recovering from the OOME). BTW: Just on the "@ test" then the normal way to exclude tests is to add the @ignore tag or else add the test to the exclude list (ProblemList.txt). Just mentioning it because someone might spot the space and wonder if it is intentional or not. -Alan.
Would adding @run main/othervm -Xmx1200M BitLengthOverflow and similarly to the other three tests be acceptable? Brian On Jan 2, 2014, at 12:34 PM, Alan Bateman wrote:
For example, in jdk/test/Makefile then you'll see that the tests are run with -vmoption:-Xmx512m.
One idea would be add an @run so that they run in othervm mode. That way there wouldn't be any question about whether the OOME would cause side effects that would impact tests that run subsequently in the same (agent) VM.
On 02/01/2014 20:47, Brian Burkhalter wrote:
Would adding
@run main/othervm -Xmx1200M BitLengthOverflow
and similarly to the other three tests be acceptable?
Brian This could potentially be problematic on Windows 32-bit but it would help if you add -Xshare:off so that you don't have the shared archive mapped. Also I assume that if you do this that the code to catch OOME should be removed.
That said, I can imagine it causing problems on small memory/embedded targets where this will exceed the total memory on the system. The real issue here of course is that we aren't using keywords or other means that allow filtering and selection of tests. This is something that will need to be tackled some day. -Alan
participants (3)
-
Alan Bateman
-
Brian Burkhalter
-
Joe Darcy