Bug ID: JDK-8034056 assert(_heap_alignment >= _space_alignment) failed: heap_alignment less than space

Versions (Unresolved/Resolved/Fixed)

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 b28Fixed

The hs_err head is:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/184312.hseigel/s/src/share/vm/memory/collectorPolicy.cpp:86), pid=25483, tid=3086252944
#  assert(_heap_alignment >= _space_alignment) failed: heap_alignment: 2097152 less than space_alignment: 4194304
#
# JRE version:  (8.0-b128) (build )
# Java VM: Java HotSpot(TM) Server VM (25.20-b03-internal-201402061843.hseigel.bug_8021774_gt2_8u-fastdebug mixed mode linux-x86 )
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# 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 (0x099d9400):  JavaThread "Unknown thread" [_thread_in_vm, id=25486, stack(0xb7ef7000,0xb7f48000)]

Stack: [0xb7ef7000,0xb7f48000],  sp=0xb7f466d0,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xdb33d5]  VMError::report_and_die()+0x185
V  [libjvm.so+0x5ca888]  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0x521333]  CollectorPolicy::initialize_flags()+0x2c3
V  [libjvm.so+0x5213c5]  GenCollectorPolicy::initialize_flags()+0x15
V  [libjvm.so+0x522f42]  TwoGenerationCollectorPolicy::initialize_flags()+0x12
V  [libjvm.so+0x71c1df]  GenerationSizer::initialize_flags()+0xf
V  [libjvm.so+0x71c3c9]  GenerationSizer::initialize_size_info()+0xb9
V  [libjvm.so+0x4fffc0]  GenCollectorPolicy::initialize_all()+0x20
V  [libjvm.so+0xba899c]  ParallelScavengeHeap::initialize()+0x5c
V  [libjvm.so+0xd625d5]  Universe::initialize_heap()+0xc5
V  [libjvm.so+0xd63598]  universe_init()+0x88
V  [libjvm.so+0x77721b]  init_globals()+0x5b
V  [libjvm.so+0xd3aad0]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x280
V  [libjvm.so+0x866e7c]  JNI_CreateJavaVM+0x8c
C  [libjli.so+0x72a8]  JavaMain+0x98

Can this test be @ignored so that this failure doesn't show up in our individual testing?
01-08-2014
The problem is that there is an initial calculation of the heap alignment and then possibly a second pass to refine the heap alignment. The initial calculation was skipped for UseParallelGC (ParallelScavengeHeap) in the general case. The comments with the code say that there was specific ParallelScavengeHeap code to do the initialization. That code took into consideration how perm gen should be aligned and likely was removed when perm gen was removed. The second pass at the heap alignment code expected some consistency (checked with an assertion) in the initial heap alignment and that consistency was not there because UseParallelGC was skipped (and no specific ParallelScavengeHeap code was executed). This fix initializes the UseParallelGC case so that it is consistent for the second pass.
08-07-2014
ILW => MLM => P4 Impact: Medium, fails during startup so no data loss. Still bad since we can't start under certain circumstances. Likelihood: Low, Only on 32-bit Linux using large pages and the system has 4MB large pages. Workaround: Medium, Turn off large pages, might lead to performance impact so medium.
10-02-2014
Issue is reproduced on linux-i586 where /proc/meminfo does not contain information about Hugepagesize with java -XX:+UseLargePages -XX:+UseParallelGC -version
10-02-2014