RFR [8043476] java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space
Hello! There was a bug in BitSet.toString() fixed with JDK-8040806. Unfortunately, the test that had come with this change started to fail with OOM. This is because it needs to create a BitSet with the bit Integer.MAX_VALUE set, so this BitSet occupies 256M. In particular, the test fails on 32-bit platforms. The proposed fix for this is: First, run in othervm mode, so we're sure that no other tests consume the heap space. And second, explicitly check that VM is able to allocate enough memory. Experiments showed that 380M seem to be the needed minimum, so I set the boundary to 512M. I've checked the updated test with JPRT on all available platforms, no failures. Would you please review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043476 WEBREV: http://cr.openjdk.java.net/~igerasim/8043476/0/webrev/ Sincerely yours, Ivan
On 25/05/2014 07:43, Ivan Gerasimov wrote:
Hello!
There was a bug in BitSet.toString() fixed with JDK-8040806. Unfortunately, the test that had come with this change started to fail with OOM. This is because it needs to create a BitSet with the bit Integer.MAX_VALUE set, so this BitSet occupies 256M. In particular, the test fails on 32-bit platforms.
The proposed fix for this is: First, run in othervm mode, so we're sure that no other tests consume the heap space. And second, explicitly check that VM is able to allocate enough memory. Experiments showed that 380M seem to be the needed minimum, so I set the boundary to 512M.
I've checked the updated test with JPRT on all available platforms, no failures.
Would you please review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043476 WEBREV: http://cr.openjdk.java.net/~igerasim/8043476/0/webrev/ Skipping the this toString test when there isn't enough heap seems okay. Using 0x20_000_000 looks a bit odd though, might be clearer to define MB as 1024*1024 and then check 512*MB, no big deal of course. I assume the System.out was just for debugging, it looks misaligned and misleading to print "Ok" before the checks.
-Alan
Thank you Alan! On 26.05.2014 16:31, Alan Bateman wrote:
On 25/05/2014 07:43, Ivan Gerasimov wrote:
Hello!
There was a bug in BitSet.toString() fixed with JDK-8040806. Unfortunately, the test that had come with this change started to fail with OOM. This is because it needs to create a BitSet with the bit Integer.MAX_VALUE set, so this BitSet occupies 256M. In particular, the test fails on 32-bit platforms.
The proposed fix for this is: First, run in othervm mode, so we're sure that no other tests consume the heap space. And second, explicitly check that VM is able to allocate enough memory. Experiments showed that 380M seem to be the needed minimum, so I set the boundary to 512M.
I've checked the updated test with JPRT on all available platforms, no failures.
Would you please review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043476 WEBREV: http://cr.openjdk.java.net/~igerasim/8043476/0/webrev/ Skipping the this toString test when there isn't enough heap seems okay. Using 0x20_000_000 looks a bit odd though, might be clearer to define MB as 1024*1024 and then check 512*MB, no big deal of course. I'll change it as you suggest.
I assume the System.out was just for debugging, it looks misaligned and misleading to print "Ok" before the checks.
Sure, it was for debugging only, I'll remove it. Sincerely yours, Ivan
-Alan
participants (2)
-
Alan Bateman
-
Ivan Gerasimov