JDK-8212005 : Epsilon elastic TLAB sizing may cause misalignment
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-10
  • Updated: 2019-09-04
  • Resolved: 2018-10-11
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 11 JDK 12
11.0.2Fixed 12 b16Fixed
Related Reports
Blocks :  
Relates :  
Description
Does not affect default x86_64, because allocation is requested in "words", HeapWord is 8 bytes long, and so allocations are naturally 8-byte aligned. But, on x86_32 where HeapWord is only 4 bytes, or on x86_64 with unusual ObjAlignmentInBytes we have to care about aligning the allocation sizes up. Otherwise, misalignment asserts would fire reliably with gc/epsilon tests:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/jdk-jdk/src/hotspot/share/gc/shared/space.cpp:595), pid=14698, tid=14703
#  assert(is_aligned(obj) && is_aligned(new_top)) failed: checking alignment
#
# JRE version:  (12.0) (fastdebug build )
# Java VM: OpenJDK Server VM (fastdebug 12-internal+0-adhoc.shade.jdk-jdk, mixed mode, tiered, epsilon gc, linux-x86)
# No core dump will be written. 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.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Dtest.class.path.prefix=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_tier1_gc/classes/2/gc/epsilon/TestHelloWorld.d:/home/shade/jdk-jdk/test/hotspot/jtreg/gc/epsilon -Dtest.src=/home/shade/jdk-jdk/test/hotspot/jtreg/gc/epsilon -Dtest.src.path=/home/shade/jdk-jdk/test/hotspot/jtreg/gc/epsilon -Dtest.classes=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_tier1_gc/classes/2/gc/epsilon/TestHelloWorld.d -Dtest.class.path=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_tier1_gc/classes/2/gc/epsilon/TestHelloWorld.d -Dtest.vm.opts=-XX:MaxRAMPercentage=6 -Dtest.tool.vm.opts=-J-XX:MaxRAMPercentage=6 -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/images/jdk -Dcompile.jdk=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/images/jdk -Dtest.timeout.factor=4.0 -Dtest.nativepath=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/images/test/hotspot/jtreg/native -XX:MaxRAMPercentage=6 -Djava.library.path=/home/shade/jdk-jdk/build/linux-x86-server-fastdebug/images/test/hotspot/jtreg/native -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC com.sun.javatest.regtest.agent.MainWrapper /home/shade/jdk-jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_tier1_gc/gc/epsilon/TestHelloWorld.d/main.0.jta

Host: sobornost, Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, 8 cores, 31G, Debian GNU/Linux 9 (stretch)
Time: Wed Oct 10 13:31:17 2018 CEST elapsed time: 0 seconds (0d 0h 0m 0s)

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

Current thread (0xf5813800):  JavaThread "Unknown thread" [_thread_in_vm, id=14703, stack(0xf593f000,0xf5990000)]

Stack: [0xf593f000,0xf5990000],  sp=0xf598ea80,  free space=318k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x157cff1]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned int)+0x241
V  [libjvm.so+0x157ddc2]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x32
V  [libjvm.so+0x9515e1]  report_vm_error(char const*, int, char const*, char const*, ...)+0x81
V  [libjvm.so+0x138188f]  ContiguousSpace::par_allocate(unsigned int)+0x7f
V  [libjvm.so+0xa6171c]  EpsilonHeap::allocate_work(unsigned int)+0x1c
V  [libjvm.so+0xa61d4e]  EpsilonHeap::allocate_new_tlab(unsigned int, unsigned int, unsigned int*)+0x1be
V  [libjvm.so+0x1081bfd]  MemAllocator::allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x52d
V  [libjvm.so+0x1082849]  MemAllocator::allocate() const+0x129
V  [libjvm.so+0x84c735]  CollectedHeap::class_allocate(Klass*, int, Thread*)+0x35
V  [libjvm.so+0xc54a86]  InstanceMirrorKlass::allocate_instance(Klass*, Thread*)+0x96
V  [libjvm.so+0xca52bc]  java_lang_Class::create_mirror(Klass*, Handle, Handle, Handle, Thread*)+0x14c
V  [libjvm.so+0xca5cc5]  java_lang_Class::fixup_mirror(Klass*, Thread*)+0x55
V  [libjvm.so+0x14fc747]  Universe::fixup_mirrors(Thread*)+0xc7
V  [libjvm.so+0x144ef05]  SystemDictionary::resolve_preloaded_classes(Thread*)+0x125
V  [libjvm.so+0x144f2ea]  SystemDictionary::initialize(Thread*)+0x21a
V  [libjvm.so+0x1504503]  Universe::genesis(Thread*)+0x363
V  [libjvm.so+0x1504f55]  universe2_init()+0x25
V  [libjvm.so+0xc3c1a8]  init_globals()+0xa8
V  [libjvm.so+0x14bb940]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x2c0
V  [libjvm.so+0xdb4695]  JNI_CreateJavaVM+0x95
C  [libjli.so+0x3806]  JavaMain+0x86
C  [libpthread.so.0+0x627a]  start_thread+0xda


Comments
Fix Request Epsilon was delivered as JDK 11 feature. Having this fix makes it usable for 32-bit platforms (as it was intended to be usable on all platforms). Patch applies cleanly and passes gc/epsilon tests, including the regression test.
17-10-2018