RFR: Precleaning should use GC workers to do actual work

Roman Kennke rkennke at redhat.com
Wed Oct 3 11:17:08 UTC 2018


Is it possible and/or does it make sense to parallelize the precleaning?

Roman

Am 03.10.18 um 13:13 schrieb Aleksey Shipilev:
> After yesterday's String Dedup fixes, sh/jdk started to fail testing with:
> 
> #  Internal Error
> (/home/jenkins/workspace/nightly/shenandoah-jdk/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp:111),
> pid=136062, tid=136069
> #  assert(thread->is_Worker_thread()) failed: Must be a worker thread
> #
> 
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0x1ad155d]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*,
> Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x15d
> V  [libjvm.so+0x1ad24f7]  VMError::report_and_die(Thread*, void*, char const*, int, char const*,
> char const*, __va_list_tag*)+0x47
> V  [libjvm.so+0xbdfa79]  report_vm_error(char const*, int, char const*, char const*, ...)+0x109
> V  [libjvm.so+0x184a346]  ShenandoahStringDedup::enqueue_candidate(oop)+0x806
> V  [libjvm.so+0x17d2742]  void ShenandoahConcurrentMark::mark_through_ref<oop, (UpdateRefsMode)0,
> (StringDedupMode)1>(oop*, ShenandoahHeap*, Padded<BufferedOverflowTaskQueue<ObjArrayChunkedTask,
> (MemoryType)5, 131072u>, 128ul>*, ShenandoahMarkingContext*)+0x1a2
> V  [libjvm.so+0x17d31bc]  ShenandoahSATBBufferClosure::do_buffer(void**, unsigned long)+0x11c
> ...
> V  [libjvm.so+0x17c1e0a]  ShenandoahConcurrentMark::preclean_weak_refs()+0x22a
> V  [libjvm.so+0x180ca50]  ShenandoahHeap::entry_preclean()+0xd0
> V  [libjvm.so+0x17f9e28]  ShenandoahControlThread::service_concurrent_normal_cycle(GCCause::Cause)+0x1d8
> V  [libjvm.so+0x17fb521]  ShenandoahControlThread::run_service()+0x861
> V  [libjvm.so+0xb3f6e2]  ConcurrentGCThread::run()+0x92
> V  [libjvm.so+0x15d4102]  thread_native_entry(Thread*)+0x112
> 
> It happens because pre-cleaning is performed by the ShControlThread itself, not GC worker. Which
> does not have worker-id designation (or even GCLABs, for that matter). It was like that because
> precleaning is not parallel in the ReferenceProcessor, but by now it is obvious to have drawbacks.
> This patch moves precleaning to a single GC worker:
>   http://cr.openjdk.java.net/~shade/shenandoah/preclean-worker/webrev.01/
> 
> Testing: tier3_gc_shenandoah
> 
> Thanks,
> -Aleksey
> 



More information about the shenandoah-dev mailing list