RFR: JDK-8211955: GC abstraction for LAB reserve

Roman Kennke rkennke at redhat.com
Wed Oct 10 11:36:36 UTC 2018


Are you sure those asserts are present without the patch? Because it
does look like it might be related to my changes...

Roman

> On 10/10/2018 11:43 AM, Roman Kennke wrote:
>> Can you do me a favour and test this on a 32bits build? I suspect that the alignment stuff is
>> entirely different there...
> x86_32 build is fine. x86_32 tier1_gc returns with lots Epsilon test failures, but I think those
> failures are present in upstream, I'll handle them separately. Failures are like this:
> 
> #  Internal Error (/home/shade/jdk-jdk/src/hotspot/share/gc/shared/space.cpp:595), pid=17562, tid=17564
> #  assert(is_aligned(obj) && is_aligned(new_top)) failed: checking alignment
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0xf5815800):  JavaThread "Unknown thread" [_thread_in_vm, id=17564,
> stack(0xf59c3000,0xf5a14000)]
> 
> Stack: [0xf59c3000,0xf5a14000],  sp=0xf5a12a80,  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+0x157c991]  VMError::report_and_die(int, char const*, char const*, char*, Thread*,
> unsigned char*, void*, void*, char const*, int, unsigned int)+0x241
> V  [libjvm.so+0x157d762]  VMError::report_and_die(Thread*, void*, char const*, int, char const*,
> char const*, char*)+0x32
> V  [libjvm.so+0x951471]  report_vm_error(char const*, int, char const*, char const*, ...)+0x81
> V  [libjvm.so+0x138125f]  ContiguousSpace::par_allocate(unsigned int)+0x7f
> V  [libjvm.so+0xa615ac]  EpsilonHeap::allocate_work(unsigned int)+0x1c
> V  [libjvm.so+0xa61bde]  EpsilonHeap::allocate_new_tlab(unsigned int, unsigned int, unsigned int*)+0x1be
> V  [libjvm.so+0x1081935]  MemAllocator::allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x4a5
> V  [libjvm.so+0x1082509]  MemAllocator::allocate() const+0x129
> V  [libjvm.so+0x84c485]  CollectedHeap::class_allocate(Klass*, int, Thread*)+0x35
> V  [libjvm.so+0xc54916]  InstanceMirrorKlass::allocate_instance(Klass*, Thread*)+0x96
> V  [libjvm.so+0xca514c]  java_lang_Class::create_mirror(Klass*, Handle, Handle, Handle, Thread*)+0x14c
> V  [libjvm.so+0xca5b55]  java_lang_Class::fixup_mirror(Klass*, Thread*)+0x55
> V  [libjvm.so+0x14fc0e7]  Universe::fixup_mirrors(Thread*)+0xc7
> V  [libjvm.so+0x144e8d5]  SystemDictionary::resolve_preloaded_classes(Thread*)+0x125
> V  [libjvm.so+0x144ecba]  SystemDictionary::initialize(Thread*)+0x21a
> V  [libjvm.so+0x1503ea3]  Universe::genesis(Thread*)+0x363
> V  [libjvm.so+0x15048f5]  universe2_init()+0x25
> V  [libjvm.so+0xc3c038]  init_globals()+0xa8
> V  [libjvm.so+0x14bb310]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x2c0
> V  [libjvm.so+0xdb4545]  JNI_CreateJavaVM+0x95
> C  [libjli.so+0x3806]  JavaMain+0x86
> C  [libpthread.so.0+0x627a]  start_thread+0xda
> 
> 
> 
> -Aleksey
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181010/6fb71f92/signature.asc>


More information about the hotspot-gc-dev mailing list