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