JDK-8209743 : [TESTBUG] java/lang/management/MemoryMXBean/LowMemoryTest2.sh fails with OutOfMemoryError running in CDS mode
  • Type: Bug
  • Component: core-svc
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-08-20
  • Updated: 2024-10-28
  • Resolved: 2018-08-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12 b09Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
The java/lang/management/MemoryMXBean/LowMemoryTest2.sh test fails with OutOfMemoryError running on JDK binary with existing CDS archive:

Exception in thread "Thread-0" java.lang.OutOfMemoryError: Metaspace
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
	at LowMemoryTest2$BoundlessLoaderThread.loadNext(LowMemoryTest2.java:139)
	at LowMemoryTest2$BoundlessLoaderThread.run(LowMemoryTest2.java:153)
	at java.base/java.lang.Thread.run(Thread.java:834)
Exception in thread "main" java.lang.RuntimeException: Test failed - notification not received!
	at LowMemoryTest2.main(LowMemoryTest2.java:257)

The test uses -XX:MaxMetaspaceSize=16m, which is probably too small with CDS enabled.
Comments
Analysis on the test failure with MaxMetaspaceSize=16m and CDS enabled: When Metaspace OOM is occurred, the VM is trying to allocate a new Klass in the class loader (LowMemoryTest2$BoundlessLoaderThread, a class loader defined by the test) meta space. It fails to expend as all meta space memory has been already committed (for both class and non-class meatspace usage) at the time. So allocation fails and OOM is reported for metaspace. #0 Metaspace::report_metadata_oome (loader_data=0x7fff94004790, word_size=66, type=MetaspaceObj::ClassType, mdtype=Metaspace::ClassType, __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/memory/metaspace.cpp:1275 #1 0x00007ffff5f1488b in Metaspace::allocate (loader_data=0x7fff94004790, word_size=66, type=MetaspaceObj::ClassType, __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/memory/metaspace.cpp:1263 #2 0x00007ffff5dc04cb in Klass::operator new (size=472, loader_data=0x7fff94004790, word_size=66, __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/oops/klass.cpp:184 #3 0x00007ffff5b217ce in InstanceKlass::allocate_instance_klass (parser=..., __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/oops/instanceKlass.cpp:369 #4 0x00007ffff57620d5 in ClassFileParser::create_instance_klass (this=0x7fffce33c880, changed_by_loadhook=false, __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/classfile/classFileParser.cpp:5513 #5 0x00007ffff5dc5377 in KlassFactory::create_from_stream (stream=0x7fffce33cc50, name=0x7fff940f7190, loader_data=0x7fff94004790, protection_domain=..., unsafe_anonymous_host=0x0, cp_patches=0x0, __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/classfile/klassFactory.cpp:222 #6 0x00007ffff6190ae4 in SystemDictionary::resolve_from_stream (class_name=0x7fff940f7190, class_loader=..., protection_domain=..., st=0x7fffce33cc50, __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/classfile/systemDictionary.cpp:1117 #7 0x00007ffff5c6c7f1 in jvm_define_class_common (env=0x7ffff0486b88, name=0x7fffce33ceb0 "Test112151", loader=0x7fffce33d368, buf=0x7fff940f70e0 "\312\376\272\276", len=125, pd=0x7fffce33d390, source=0x7ffff6670419 "__JVM_DefineClass__", __the_thread__=0x7ffff0486800) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/prims/jvm.cpp:935 #8 0x00007ffff5c6cd0c in JVM_DefineClassWithSource (env=0x7ffff0486b88, name=0x7fffce33ceb0 "Test112151", loader=0x7fffce33d368, buf=0x7fff940f70e0 "\312\376\272\276", len=125, pd=0x7fffce33d390, source=0x0) at /export/users/jiangli/jdk_default_archive/open/src/hotspot/share/prims/jvm.cpp:955 #9 0x00007ffff46474f2 in Java_java_lang_ClassLoader_defineClass1 (env=0x7ffff0486b88, cls=0x7fffce33d398, loader=0x7fffce33d368, name=0x7fffce33d370, data=0x7fffce33d378, offset=0, length=125, pd=0x7fffce33d390, source=0x0) at /export/users/jiangli/jdk_default_archive/open/src/java.base/share/native/libjava/ClassLoader.c:136 Here is the metaspace usage at the OOM time: (gdb) call MetaspaceUtils::print_basic_report(tty, 0) Usage: Non-class: 9.12 MB capacity, 6.07 MB ( 67%) used, 3.03 MB ( 33%) free+waste, 19.25 KB ( <1%) overhead. Class: 6.72 MB capacity, 6.38 MB ( 95%) used, 334.73 KB ( 5%) free+waste, 20.38 KB ( <1%) overhead. Both: 15.85 MB capacity, 12.45 MB ( 79%) used, 3.36 MB ( 21%) free+waste, 39.62 KB ( <1%) overhead. Virtual space: Non-class space: 10.00 MB reserved, 9.25 MB ( 92%) committed Class space: 8.00 MB reserved, 6.75 MB ( 84%) committed Both: 18.00 MB reserved, 16.00 MB ( 89%) committed Chunk freelists: Non-Class: 1.00 KB Class: 3.50 KB Both: 4.50 KB 79% of total metaspsce is used (note, this is not the same as committed memory) at OOM time. The test expects 80% of usage (for all monitored spaces) before stopping defining new class. Therefore, the test continues to define new classes and hits the metaspace OOM. When CDS is enabled, more classes are actually defined. Running the test with ' -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics' showing 13171 classes are defined with CDS is enabled and 7950 classes is defined without CDS: java -XX:MaxRAMPercentage=1 -ea -esa -Xmx64m -noclassgc -XX:MaxMetaspaceSize=16m -XX:+UseParallelGC -cp ./JTwork/classes/java/lang/management/MemoryMXBean/LowMemoryTest2.d/ -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics LowMemoryTest2 - Class (reserved=19404KB, committed=17356KB) (classes #13171) ( instance classes #13065, array classes #106) java -XX:MaxRAMPercentage=1 -ea -esa -Xmx64m -noclassgc -XX:MaxMetaspaceSize=16m -XX:+UseParallelGC -cp ./JTwork/classes/java/lang/management/MemoryMXBean/LowMemoryTest2.d/ -XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics -Xshare:off LowMemoryTest2 - Class (reserved=19144KB, committed=15176KB) (classes #7950) ( instance classes #7833, array classes #117) In conclusion, this is a test bug. Increasing the metaspace space size can change the proportion (class and non-class allocation types) of the meta space usage and allow the test to pass, although it is not a real fix to the test issue.
01-09-2018

URL: http://hg.openjdk.java.net/jdk/jdk/rev/30a2c149fd7e User: ccheung Date: 2018-08-28 23:22:57 +0000
28-08-2018

On a linux-x64 host with 12 cores and 60103904 kB total mem. Test ran with fastdebug build. jtreg with -vmoptions:'-XX:MaxRAMPercentage=1 -ea -esa -Xmx64m' MaxMetaspaceSize (MB) 16* 24 32 elapsed time (s) 27 41 62 (*) test failed with OOME
28-08-2018

The problem was reproducible locally on linux-x64 with the following vmoptons: -XX:MaxRAMPercentage=1 -ea -esa -Xmx64m LowMemoryTest2.sh contains the following 4 tests: -noclassgc -XX:MaxMetaspaceSize=16m -XX:+UseSerialGC LowMemoryTest2 -noclassgc -XX:MaxMetaspaceSize=16m -XX:+UseParallelGC LowMemoryTest2 -noclassgc -XX:MaxMetaspaceSize=16m -XX:+UseConcMarkSweepGC LowMemoryTest2 # Test class metaspace - might hit MaxMetaspaceSize instead if # UseCompressedClassPointers is off or if 32 bit. -noclassgc -XX:MaxMetaspaceSize=16m -XX:CompressedClassSpaceSize=4m LowMemoryTest2 The first 3 failed with OOME. The test passed if the MaxMetaSpaceSize is increased to 32m.
27-08-2018