JDK-8255917 : runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2020-11-05
  • Updated: 2022-06-27
  • Resolved: 2020-12-15
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 17
17 b02Fixed
Related Reports
Duplicate :  
JDK-8256729 - [windows] runtime/cds/SharedBaseAddress.java: assert on split_reserved_memory
Duplicate :  
JDK-8256213 - Remove os::split_reserved_memory
Relates :  
JDK-8255954 - [windows] UseNUMAInterleaving causes VM to balloon and hang
Relates :  
JDK-8263915 - runtime/cds/appcds/MismatchedPathTriggerMemoryRelease.java fails when UseCompressedClassPointers is off
Relates :  
JDK-8255978 - [windows] os::release_memory may not release the full range
Relates :  
JDK-8256079 - Heterogeneous Heap may fail silently on Windows
Relates :  
JDK-8255973 - Add more logging to debug JDK-8255917
Relates :  
JDK-8253649 - Potential bug in os::split_reserved_memory on windows
Relates :  
JDK-8256864 - [windows] Improve tracing for mapping errors
Sub Tasks
JDK-8255973 :  
Add more logging to debug JDK-8255917 - Resolved
Description
The following test failed in the JDK16 CI:

runtime/cds/SharedBaseAddress.java

Here's a snippet from the log file:

----------System.err:(63/4301)*----------
 stdout: [[0.116s][info][cds] trying to map SharedBaseAddress0.jsa
[0.116s][info][cds] Opened archive SharedBaseAddress0.jsa.
[0.116s][info][cds] Archive was created with UseCompressedOops = 0, UseCompressedClassPointers = 1
[0.116s][info][cds] full module graph: disabled because archive was created without full module graph
[0.116s][info][cds] Archive(s) were created with -XX:SharedBaseAddress=0. Always map at os-selected address.
[0.116s][info][cds] Try to map archive(s) at an alternative address
[0.117s][debug][cds] Reserved archive_space_rs     [0x0000027a00000000 - 0x0000027a01000000] (16777216) bytes
[0.117s][debug][cds] Reserved class_space_rs [0x0000027a01000000 - 0x0000027a41000000] (1073741824) bytes
[0.117s][info ][cds] Commit static  region #0 at base 0x0000027a00000000 top 0x0000027a00010000 (MiscCode) exec
[0.117s][info ][cds] Mapped static  region #0 at base 0x0000027a00000000 top 0x0000027a00010000 (MiscCode)
[0.117s][info ][cds] Commit static  region #1 at base 0x0000027a00010000 top 0x0000027a00480000 (ReadWrite)
[0.121s][info ][cds] Mapped static  region #1 at base 0x0000027a00010000 top 0x0000027a00480000 (ReadWrite)
[0.121s][info ][cds] Commit static  region #2 at base 0x0000027a00480000 top 0x0000027a00c10000 (ReadOnly)
[0.128s][info ][cds] Mapped static  region #2 at base 0x0000027a00480000 top 0x0000027a00c10000 (ReadOnly)
[0.128s][debug][cds,reloc] runtime archive relocation start
[0.128s][debug][cds,reloc] mapped relocation bitmap @ 0x0000027a01200000 (1577449 bits)
[0.128s][debug][cds,reloc] SharedDataRelocator::_patch_base     = 0x0000027a00000000
[0.128s][debug][cds,reloc] SharedDataRelocator::_patch_end      = 0x0000027a00c10000
[0.128s][debug][cds,reloc] SharedDataRelocator::_valid_old_base = 0x0000000000000000
[0.128s][debug][cds,reloc] SharedDataRelocator::_valid_old_end  = 0x0000000000c10000
[0.128s][debug][cds,reloc] SharedDataRelocator::_valid_new_base = 0x0000027a00000000
[0.128s][debug][cds,reloc] SharedDataRelocator::_valid_new_end  = 0x0000027a00c10000
[0.139s][debug][cds,reloc] runtime archive relocation done
[0.139s][info ][cds      ] optimized module handling: enabled
[0.139s][info ][cds      ] full module graph: disabled
[0.140s][info ][cds      ] Unmapping region #3 at base 0x0000027a01200000 (Bitmap)
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=t:/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:433
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:433), pid=1486656, tid=409592
#  assert(reserved_rgn != 0LL) failed: No reserved region
#
# JRE version:  (16.0+22) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-ea+22-1336, mixed mode, sharing, tiered, z gc, windows-amd64)
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_runtime\\scratch\\0\\hs_err_pid1486656.mdmp
#
# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_runtime\\scratch\\0\\hs_err_pid1486656.log
#
#

Command Line: -XX:MaxRAMPercentage=3 -Djava.io.tmpdir=t:/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/tmp -XX:+CreateCoredumpOnCrash -XX:+UseZGC -XX:SharedBaseAddress=0 -Xlog:cds=debug -Xlog:cds+reloc=debug -XX:NativeMemoryTracking=detail -Xshare:on -Dtest.timeout.factor=4.0 -XX:SharedArchiveFile=SharedBaseAddress0.jsa 


Here's the crashing thread's stack:

---------------  T H R E A D  ---------------

Current thread (0x0000027a61d5b3e0):  JavaThread "Unknown thread" [_thread_in_vm, id=409592, stack(0x000000f1cc900000,0x000000f1cca00000)]

Stack: [0x000000f1cc900000,0x000000f1cca00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xaf00e1]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:236)
V  [jvm.dll+0xd180b7]  VMError::report+0xfb7  (vmError.cpp:731)
V  [jvm.dll+0xd19a3e]  VMError::report_and_die+0x7de  (vmError.cpp:1548)
V  [jvm.dll+0xd1a0f4]  VMError::report_and_die+0x64  (vmError.cpp:1341)
V  [jvm.dll+0x4c3ec7]  report_vm_error+0x117  (debug.cpp:267)
V  [jvm.dll+0xd0dcc1]  VirtualMemoryTracker::add_committed_region+0x101  (virtualMemoryTracker.cpp:433)
V  [jvm.dll+0xae0cb7]  MemTracker::record_virtual_memory_commit+0x97  (memTracker.hpp:240)
V  [jvm.dll+0xaddde0]  os::commit_memory+0xb0  (os.cpp:1674)
V  [jvm.dll+0xd1181d]  metaspace::VirtualSpaceNode::commit_range+0x11d  (virtualSpaceNode.cpp:107)
V  [jvm.dll+0xa59a96]  metaspace::Metachunk::commit_up_to+0x306  (metachunk.cpp:103)
V  [jvm.dll+0x3ecbd1]  metaspace::ChunkManager::get_chunk+0x341  (chunkManager.cpp:202)
V  [jvm.dll+0xa5ef44]  metaspace::MetaspaceArena::allocate+0x2d4  (metaspaceArena.cpp:288)
V  [jvm.dll+0xa5c409]  Metaspace::allocate+0x179  (metaspace.cpp:796)
V  [jvm.dll+0xac47c8]  ObjArrayKlass::allocate_objArray_klass+0x358  (objArrayKlass.cpp:121)
V  [jvm.dll+0x67f390]  InstanceKlass::array_klass_impl+0xf0  (instanceKlass.cpp:1452)
V  [jvm.dll+0x67f261]  InstanceKlass::allocate_objArray+0x61  (instanceKlass.cpp:1388)
V  [jvm.dll+0xc5f3dd]  SystemDictionaryShared::allocate_shared_data_arrays+0x16d  (systemDictionaryShared.cpp:1104)
V  [jvm.dll+0xa651b6]  MetaspaceShared::post_initialize+0x26  (metaspaceShared.cpp:360)
V  [jvm.dll+0xccfa96]  universe_post_init+0x776  (universe.cpp:1003)
V  [jvm.dll+0x67c3cf]  init_globals+0xaf  (init.cpp:151)
V  [jvm.dll+0xc9eff1]  Threads::create_vm+0x621  (thread.cpp:3579)
V  [jvm.dll+0x759762]  JNI_CreateJavaVM_inner+0xb2  (jni.cpp:3764)
V  [jvm.dll+0x75c72f]  JNI_CreateJavaVM+0x1f  (jni.cpp:3847)
C  [jli.dll+0x53ef]  JavaMain+0x113  (java.c:416)
C  [ucrtbase.dll+0x21ffa]
C  [KERNEL32.DLL+0x17974]
C  [ntdll.dll+0x6a271]
Comments
Changeset: 36e20974 Author: Yumin Qi <minqi@openjdk.org> Date: 2020-12-15 16:52:26 +0000 URL: https://git.openjdk.java.net/jdk/commit/36e20974
15-12-2020
[~stuefe] We could backport the fix to jdk16 (jdk16 cf on Dec 10, 2020).
14-12-2020
Should this not be fixed in JDK16 too?
14-12-2020
I think it's best to remove os::split_reserved_memory(). I don't think it can be reliably implemented. For example, when the JVM is embedded by a larger program using JNI_CreateJavaVM(), competing threads in the program could call malloc while we are inside os::split_reserved_memory(). We can add an assert so that spaces created using ReservedSpace::first/last part are not released individually. But that's an independent issue -- currently only CDS calls ReservedSpace::first_part() with split=true. All other calls to first_part specify split=false, so they are unaffected by the removal of os::split_reserved_memory().
01-12-2020
Nice finding! Do we still want to go ahead with removing os::split_reserved_memory() or make it more robust? - removing it means having to think about callers of ReservedSpace::first/last part - especially making sure that no-one releases those accidentally. Since that would affect the other parts as well. - retaining it may be simpler, just switch to "raw" VirtualAlloc and VirtualFree. Or at least call the pd_xxx versions which do not log or do NMT stuff. Then, we need to handle the NMT registration separately like we do for Posix platforms.
01-12-2020
The above dump concurs with [~stuefe]'s theory https://bugs.openjdk.java.net/browse/JDK-8256729?focusedCommentId=14382683&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382683 -> After we have reserved the CDS region, NMT malloc's which causes the OS to allocate a block inside where we want the CCS to be.
01-12-2020
I have analyzed hs_err_pid1486656.mdmp (from the mach5-one-jdk-16+22-1336-tier3-20201029-0625-15399686 failure) using WinDBG. With the "!address" command, we can see that in the "bad" case, the O/S has allocated a malloc chunk at where we wanted the CCS (Compressed Class Space) to be. That's why NMT has no record for the CCS space. For better formatting of the following, see https://bugs.openjdk.java.net/secure/attachment/91892/windbg.txt ============================================ Good: java -XX:ArchiverelocationMode=1 3a`ea5f2000 3a`ea5f5000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE|PAGE_GUARD <unknown> 3a`ea5f5000 3a`ea600000 0`0000b000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................] + 3a`ea600000 21c`80000000 1e1`95a00000 MEM_FREE PAGE_NOACCESS Free + CDS 21c`80000000 21c`80010000 0`00010000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READWRITE <unknown> [................] CDS 21c`80010000 21c`80c10000 0`00c00000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [.b..............] pad 21c`80c10000 21c`81000000 0`003f0000 MEM_PRIVATE MEM_RESERVE <unknown> + CCS 21c`81000000 21c`81040000 0`00040000 MEM_PRIVATE MEM_RESERVE <unknown> CCS 21c`81040000 21c`81050000 0`00010000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [Pd..............] CCS 21c`81050000 21c`c1000000 0`3ffb0000 MEM_PRIVATE MEM_RESERVE <unknown> + O/S 21c`c1000000 21c`c13ff000 0`003ff000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Heap [ID: 0; Handle: 0000021cc4970000; Type: Segment] ====================================================================== Bad: hs_err_pid1486656.mdmp f1`ce2fe000 f1`ce300000 0`00002000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~29; 16af40.13c55c] + f1`ce300000 27a`00000000 188`31d00000 MEM_FREE PAGE_NOACCESS Free + CDS 27a`00000000 27a`00010000 0`00010000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READWRITE <unknown> [................] CDS 27a`00010000 27a`00c10000 0`00c00000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [.b..z...........] pad 27a`00c10000 27a`01000000 0`003f0000 MEM_PRIVATE MEM_RESERVE <unknown> >> CSS should have been here but os::os::split_reserved_memory() has failed + O/S 27a`01000000 27a`011ff000 0`001ff000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Heap [ID: 0; Handle: 0000027a60f20000; Type: Segment] ... 27a`011ff000 27a`01200000 0`00001000 MEM_PRIVATE MEM_RESERVE <unknown> + 27a`01200000 27a`015ff000 0`003ff000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Heap [ID: 0; Handle: 0000027a60f20000; Type: Segment] 27a`015ff000 27a`01600000 0`00001000 MEM_PRIVATE MEM_RESERVE <unknown> + 27a`01600000 27a`016f2000 0`000f2000 MEM_MAPPED MEM_COMMIT PAGE_READONLY <unknown> [MZ..............] + 27a`016f2000 27a`01700000 0`0000e000 MEM_FREE PAGE_NOACCESS Free + 27a`01700000 27a`01705000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [..............JL] 27a`01705000 27a`01707000 0`00002000 MEM_PRIVATE MEM_RESERVE <unknown> 27a`01707000 27a`0170c000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [0BC.KBGGAEHG..JA] 27a`0170c000 27a`0170d000 0`00001000 MEM_PRIVATE MEM_RESERVE <unknown> + 27a`0170d000 27a`01710000 0`00003000 MEM_FREE PAGE_NOACCESS Free + 27a`01710000 27a`01711000 0`00001000 MEM_MAPPED MEM_COMMIT PAGE_READONLY <unknown> [MZ..............] + 27a`01711000 27a`01720000 0`0000f000 MEM_FREE PAGE_NOACCESS Free
01-12-2020
See comments at https://bugs.openjdk.java.net/browse/JDK-8256729
22-11-2020
Both JDK-8256367 and JDK-8255978 are now upstream and should improve error analysis. If this happens and it is, as we suspect, a problem with split_memory or release() (see also JDK-8256729), we should now see more info, e.g. memory mappings, in the jtr.
21-11-2020
One possible reason for this error could be JDK-8255978. Which is open for RFR.
18-11-2020
Commit on Windows should do some rational error checking and logging. I created https://bugs.openjdk.java.net/browse/JDK-8256255 to track that. We should not have to rely on NMT accidentally detecting that the range we try to commit was not reserved.
12-11-2020
ILW = HLM = P3
10-11-2020
From https://xxxxxx/mdash/jobs/mach5-one-jdk-16+22-1336-tier3-20201029-0625-15399686/results?search=status%3Afailed%20AND%20-state%3Ainvalid Reserved archive_space_rs [0x0000027a00000000 - 0x0000027a01000000] (16777216 ) bytes Reserved class_space_rs [0x0000027a01000000 - 0x0000027a41000000] (1073741824) bytes ... mapped relocation bitmap @ 0x0000027a01200000 (1577449 bits) In this test, ZGC is executed with +UseCompressedClassPointers, so we reserve the class space immediately above the CDS archive. However, the log later shows that the bitmap is also mapped inside class_space_rs (0x0000027a01000000 < 0x0000027a01200000 < 0x0000027a41000000). This is possibly only if the class_space_rs reservation has failed. Its caused by a bug in ReservedSpace::first_part(). Please see the description of JDK-8256079 for details. We can work around the bug in ReservedSpace::first_part() by calling it with split==false. Here's a suggested fix: https://github.com/openjdk/jdk/blob/f71f9dc93a6963ce36953e0ad770edd761afd0b4/src/hotspot/share/memory/metaspaceShared.cpp#L1639 if (MetaspaceShared::use_windows_memory_mapping() && use_archive_base_addr == true) { // new special handling code for Windows do not reserve total_rs; reserve archive_space_rs; reserve class_space_rs; // i.e. do not call ReservedSpace::first_part() at all // after this function returns, archive_space_rs is released anyway .... } else { // the following is existing code .... ReservedSpace total_rs; if (base_address != NULL) { // Reserve at the given archive base address, or not at all. total_rs = ReservedSpace(total_range_size, archive_space_alignment, false /* bool large */, (char*) base_address); } else { // Reserve at any address, but leave it up to the platform to choose a good one. total_rs = Metaspace::reserve_address_space_for_compressed_classes(total_range_size); } .... // Now split up the space into ccs and cds archive. For simplicity, just leave // the gap reserved at the end of the archive space. archive_space_rs = total_rs.first_part(ccs_begin_offset, (size_t)os::vm_allocation_granularity(), - /*split=*/true); + /*split=*/!MetaspaceShared::use_windows_memory_mapping()); class_space_rs = total_rs.last_part(ccs_begin_offset); As noted in JDK-8256079, split==true is necessary if we are mmap'ing into the first part of total_rs. However, on Windows, when (base_address == NULL), the CDS archive is NOT mmap'ed. Instead, it's read into the memory using ::read().
10-11-2020
For reference, here's a "good" execution with the same VM parameters as the failed case from the above comment. I set a break point at the exact location (first call of VirtualMemoryTracker::add_committed_region by the very first call of Metaspace::allocate). $ java -XX:+UseZGC -Xlog:cds -Xshare:dump -XX:SharedBaseAddress=0 $ java -XX:+UseZGC -Xlog:cds -XX:NativeMemoryTracking=detail -version >Debug.Print VirtualMemoryTracker::_reserved_regions->_head->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_data VirtualMemoryRegion: {_base_address=0x0000021880000000 "" _size=0x0000000001000000 } >Debug.Print VirtualMemoryTracker::_reserved_regions->_head->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_data VirtualMemoryRegion: {_base_address=0x0000021881000000 _size=0x0000000040000000 } >Debug.Print addr 0x0000021881040000 "" >Debug.Print size 0x0000000000010000 >Debug.Print SharedBaseAddress 0x0000021880000000 >Debug.Print addr >Debug.Print size >Debug.Print SharedBaseAddress
06-11-2020
I decoded the stack by hand from hs_err_pid1486656.mdmp (from the mach5-one-jdk-16+22-1336-tier3-20201029-0625-15399686 failure) from this call: V [jvm.dll+0xd0dcc1] VirtualMemoryTracker::add_committed_region+0x101 (virtualMemoryTracker.cpp:433) V [jvm.dll+0xae0cb7] MemTracker::record_virtual_memory_commit+0x97 (memTracker.hpp:240) VirtualMemoryTracker::add_committed_region((address)addr, size, stack); 00007FFBEA760CA3 mov r8,qword ptr [rsp+50h] stack 00007FFBEA760CA8 mov rdx,qword ptr [rsp+48h] size == 0x0000000000010000 = 65536 00007FFBEA760CAD mov rcx,qword ptr [rsp+40h] addr == 0x0000027a01040000 00007FFBEA760CB2 call 00007FFBEA98DBC0 00007FFBEA760CB7 lea rcx,[tc] [A] = return address (jvm.dll+0xae0cb7 == 0x00007ffbea760cb7) [B] = addr @ [rsp+40h] [C] = size @ [rsp+48h 0x000000F1CC9FEC28 0000000000000000 0000027a60f3b750 0000027a01040000 0000000000000000 [A]>00007ffbea760cb7 0x000000F1CC9FEC50 0000027a01040000 0000000000010000 000000f1cc9fece0 0000000000000001 00007ffbeac8bd60 0x000000F1CC9FEC78 0000027a01040000 0000000000000001 00007ffbea75dde0 [B]>0000027a01040000 [C]>0000000000010000 I printed out the contents of VirtualMemoryTracker::_reserved_regions. The following are two consecutive nodes in the linked list: >Debug.Print VirtualMemoryTracker::_reserved_regions->_head->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_data VirtualMemoryRegion: {_base_address=0x0000027a00000000 "" _size=0x0000000001000000 } _flag: mtClassShared (0x0000000c) >Debug.Print VirtualMemoryTracker::_reserved_regions->_head->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_next->_data VirtualMemoryRegion: {_base_address=0x0000027a61100000 <Error reading characters of string.> _size=0x0000000000002000 } _flag: mtSafepoint (0x00000014) >Debug.Print SharedBaseAddress 0x0000027a00000000 You can see that there's no ReservedMemoryRegion that covers the requested area of {0x0000027a01040000, size = 65536}
06-11-2020
The debug is stuck at no available thread local info available. I could check the global variable like VirtualMemoryTracker::_reserved_regions, it is a long linked list, then even with a valid local 'rgn', compare it manually is not a good way to go. We need log more info for VirtualMemoryTracker. It looks there is bug in NMT.
06-11-2020
From the log: [0.139s][info ][cds ] full module graph: disabled [0.140s][info ][cds ] Unmapping region #3 at base 0x0000027a01200000 (Bitmap) That indicates the regions already unmapped. Since it is on Windows, FileMapRegion._is_mapped_from_file = false. But Bitmap region is different from other 3, so it is set to true. This is why we can see the Unmapping information for Bitmap only since: if (mapped_base != NULL) { if (size > 0 && si->mapped_from_file()) { log_info(cds)("Unmapping region #%d at base " INTPTR_FORMAT " (%s)", i, p2i(mapped_base), shared_region_name[i]); if (!os::unmap_memory(mapped_base, size)) { fatal("os::unmap_memory failed"); } }
06-11-2020
The assert happens on the very first allocation from metaspace. I.e., the first call to Metaspace::allocate(): V [jvm.dll+0x4c3ec7] report_vm_error+0x117 (debug.cpp:267) V [jvm.dll+0xd0dcc1] VirtualMemoryTracker::add_committed_region+0x101 (virtualMemoryTracker.cpp:433) V [jvm.dll+0xae0cb7] MemTracker::record_virtual_memory_commit+0x97 (memTracker.hpp:240) V [jvm.dll+0xaddde0] os::commit_memory+0xb0 (os.cpp:1674) V [jvm.dll+0xd1181d] metaspace::VirtualSpaceNode::commit_range+0x11d (virtualSpaceNode.cpp:107) V [jvm.dll+0xa59a96] metaspace::Metachunk::commit_up_to+0x306 (metachunk.cpp:103) V [jvm.dll+0x3ecbd1] metaspace::ChunkManager::get_chunk+0x341 (chunkManager.cpp:202) V [jvm.dll+0xa5ef44] metaspace::MetaspaceArena::allocate+0x2d4 (metaspaceArena.cpp:288) V [jvm.dll+0xa5c409] Metaspace::allocate+0x179 (metaspace.cpp:796) <<<<<<<<<<<<< VERY FIRST CALL!! V [jvm.dll+0xac47c8] ObjArrayKlass::allocate_objArray_klass+0x358 (objArrayKlass.cpp:121) V [jvm.dll+0x67f390] InstanceKlass::array_klass_impl+0xf0 (instanceKlass.cpp:1452) V [jvm.dll+0x67f261] InstanceKlass::allocate_objArray+0x61 (instanceKlass.cpp:1388) V [jvm.dll+0xc5f3dd] SystemDictionaryShared::allocate_shared_data_arrays+0x16d (systemDictionaryShared.cpp:1104) V [jvm.dll+0xa651b6] MetaspaceShared::post_initialize+0x26 (metaspaceShared.cpp:360) V [jvm.dll+0xccfa96] universe_post_init+0x776 (universe.cpp:1003) V [jvm.dll+0x67c3cf] init_globals+0xaf (init.cpp:151) V [jvm.dll+0xc9eff1] Threads::create_vm+0x621 (thread.cpp:3579) Also, we are running with (UseCompressedClassPointers == 1), so this allocation comes out of the compressed class space. So for some reason, when we try to commit the very first block of memory in the CSS, VirtualMemoryTracker cannot find a ReservedMemoryRegion for this block: bool VirtualMemoryTracker::add_committed_region(address addr, size_t size, const NativeCallStack& stack) { assert(addr != NULL, "Invalid address"); assert(size > 0, "Invalid size"); assert(_reserved_regions != NULL, "Sanity check"); ReservedMemoryRegion rgn(addr, size); ReservedMemoryRegion* reserved_rgn = _reserved_regions->find(rgn); assert(reserved_rgn != NULL, "No reserved region"); <<<<< assert failed
06-11-2020