JDK-8038422 : CDS test failed: assert((size % os::vm_allocation_granularity()) == 0) failed when limiting SharedMiscDataSize
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u20,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: windows
  • Submitted: 2014-03-26
  • Updated: 2015-01-21
  • Resolved: 2014-05-16
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 8 JDK 9
8u40Fixed 9 b17Resolved
Related Reports
Relates :  
JDK-8038268 - VM Crashes in MetaspaceShared::generate_vtable_methods while creating CDS archive with limiting SharedMiscCodeSize
Description
assert((size % os::vm_allocation_granularity()) == 0) failed: size not allocation aligned

Windows only, this one found on Windows-x64
Reproducible: 100%
JDK: jdk9_b04 fastdebug
CMD: C:\\jdk\\jdk9_b04_fd\\fastdebug\\bin\\java.exe -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=./test.jsa -XX:SharedMiscDataSize=500k -Xshare:dump
Comments
> The right check should be against max_alignment not vm_allocation_granularity. I don't think that is what was meant to be written.
23-05-2014
The problem found: in set_max_alignment, we use vm_page_size, which is 4096, on the test machine. But for vm_allocation_granularity, it is 64K. _vm_page_size = si.dwPageSize; _vm_allocation_granularity = si.dwAllocationGranularity; They are different! If they are consistent, we would not see the failure. This explains: 512000 is aligned with 4K, but not 64K. The right check should be against max_alignment not vm_allocation_granularity.
22-05-2014
This part of code did not change the value of SharedMiscDataSize: Metaspace::global_initialize() : if (DumpSharedSpaces) { SharedReadOnlySize = align_size_up(SharedReadOnlySize, max_alignment); SharedReadWriteSize = align_size_up(SharedReadWriteSize, max_alignment); SharedMiscDataSize = align_size_up(SharedMiscDataSize, max_alignment); SharedMiscCodeSize = align_size_up(SharedMiscCodeSize, max_alignment); That is very strange. 512000 aligned with 4096 should be 524288, but it did not change!
21-05-2014
SharedMiscDataSize is given in this command-line argument in the bug report: -XX:SharedMiscDataSize=500k
20-05-2014
I tested most recent JDK9 passed, but I still saw the failure with 8u20 the fcs. I will test the recent 8uxx, will update you. The failure is at this part: // Now split into misc sections. ReservedSpace md_rs = misc_section.first_part(SharedMiscDataSize); ReservedSpace mc_rs = misc_section.last_part(SharedMiscDataSize); SharedMiscDataSize is 512000 which is not aligned with page size. I now don't know where the number is from, still in debugging for it. It should be 4M with 64bit.
20-05-2014
Yumin, which is the "most recent version" you tested against? Is it JDK9? Does the fix need to be back ported to 8u40?
19-05-2014
Closed since no longer reproducible with updated versions.
16-05-2014
With the most recent version, I could not repeat the result. I think the problem is: In older version, we did not align address used to map the space. The variable, shared_base, is not added in that version since in debugger, I could not see this variable. I could not find the code for that version too since the code in the ws/hotspot under /java/re/jdk is like updated version with this variable added. The above failure I got, could not get too with the most recent version. So it is fixed in some earlier version.
09-05-2014
KernelBase.dll!_DebugBreak@0() Unknown jvm.dll!VMError::show_message_box(char * buf, int buflen) Line 61 C++ jvm.dll!VMError::report_and_die() Line 915 C++ jvm.dll!report_vm_error(const char * file, int line, const char * error_msg, const char * detail_msg) Line 223 C++ jvm.dll!ReservedSpace::first_part(unsigned int partition_size, unsigned int alignment, bool split, bool realloc) Line 247 C++ jvm.dll!VM_PopulateDumpSharedSpace::VM_PopulateDumpSharedSpace(ClassLoaderData * loader_data, GrowableArray<Klass *> * class_promote_order) Line 410 C++ jvm.dll!MetaspaceShared::preload_and_dump(Thread * __the_thread__) Line 767 C++ > jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool * canTryAgain) Line 3484 C++ jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void * args) Line 5191 C++ java.exe!012213c1() Unknown [Frames below may be incorrect and/or missing, no symbols loaded for java.exe] java.exe!01221e7e() Unknown java.exe!0122cfa7() Unknown java.exe!0122ab3a() Unknown java.exe!0122abc4() Unknown kernel32.dll!@BaseThreadInitThunk@12() Unknown ntdll.dll!___RtlUserThreadStart@8() Unknown ntdll.dll!__RtlUserThreadStart@8() Unknown It failed with VM_PopulateDumpSharedSpace. ReservedSpace::ReservedSpace(char* base, size_t size, size_t alignment, bool special, bool executable) { assert((size % os::vm_allocation_granularity()) == 0, "size not allocation aligned"); _base = base; _size = size; _alignment = alignment; _noaccess_prefix = 0; _special = special; _executable = executable; } size is int metadata_size = SharedReadOnlySize+SharedReadWriteSize; It is not aligned with page size. The page on the test is 64K, but the size here is 512000. The assert failed.
01-05-2014
ILW: HLL => P4 I: High - assertion L: Low, unlikely use case W: Low, increase SharedMiscDataSize
18-04-2014
I am not sure if the bug is a P3, because it's caused by a flag that the user normally doesn't change. So this bug will not happen in real world usage. The main problem is when writing into the "md" (misc data) region of the archive, there is no out-of-bounds check. The default SharedMiscDataSize is so big that you will never overflow the MD region with the default classlist (only 3.3% of MD is used, vs 37.4% of RO and 59.1% of RW). ro space: 6937600 [ 37.4% of total] out of 16777216 bytes [41.4% used] at 0x0000000800000000 rw space: 10975600 [ 59.1% of total] out of 16777216 bytes [65.4% used] at 0x0000000801000000 md space: 612952 [ 3.3% of total] out of 4194304 bytes [14.6% used] at 0x0000000802000000 mc space: 34053 [ 0.2% of total] out of 122880 bytes [27.7% used] at 0x0000000802400000 It's true that you can add more classes to the classlist to increase the usage of the MD space. However, doing so will cause either RO or RW spaces to overflow first. There are overflow checks for those two regions, so the VM will exit cleanly without crashing. I think we should investigate this bug to see why this happens only on win32 and not win64. If we don't find anything suspicious (other than the result of simply overflowing the MD region), we should defer to 9 (same as JDK-8038268). I have a preliminary/partial fix for this in my 8u40 repo -- I added out-of-bound checks when writing the symbol table and string table into the MD space. However, the changes are quite involved (for JDK-8021834) and not easily back-ported to 8u20.
16-04-2014
# # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (D:\re\puppet\workspace\9-2-build-windows-amd64-cygwin\jdk9\176\hotspot\src\share\vm\runtime\virtualspace.cpp:230), pid=5528, tid=4144 # assert((size % os::vm_allocation_granularity()) == 0) failed: size not allocation aligned # # JRE version: (9.0-b04) (build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b62-fastdebug interpreted mode windows-amd64 compressed oops) # Core dump written. Default location: C:\temp\cdsTests\JTwork\scratch\hs_err_pid5528.mdmp # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00000000022ab000): JavaThread "Unknown thread" [_thread_in_vm, id=4144, stack(0x00000000020f0000,0x00000000021f0000)] Stack: [0x00000000020f0000,0x00000000021f0000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x48759a] V [jvm.dll+0x39c5ee] V [jvm.dll+0x39d26a] V [jvm.dll+0x38f540] V [jvm.dll+0x351cc4] V [jvm.dll+0x352267] V [jvm.dll+0x164407] V [jvm.dll+0x1652ed] V [jvm.dll+0x34a5f4] V [jvm.dll+0x220ff4] C [java.exe+0x213a] C [java.exe+0xcad7] C [java.exe+0xcb6b] C [kernel32.dll+0x1652d] C [ntdll.dll+0x2c541] --------------- P R O C E S S --------------- Java Threads: ( => current thread ) =>0x00000000022ab000 JavaThread "Unknown thread" [_thread_in_vm, id=4144, stack(0x00000000020f0000,0x00000000021f0000)] Other Threads: 0x0000000016db1800 VMThread [stack: 0x00000000180f0000,0x00000000181f0000] [id=6440] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None
26-03-2014