RFR: Fix and enable parallel safepoint workers
Aleksey Shipilev
shade at redhat.com
Fri Sep 14 15:07:34 UTC 2018
On 09/14/2018 05:06 PM, Roman Kennke wrote:
> Am 14.09.2018 um 17:03 schrieb Aleksey Shipilev:
>> On 09/14/2018 03:17 PM, Roman Kennke wrote:
>>> We do have an implementation of SH::get_safepoint_workers() but it is
>>> broken:
>>> - the workers don't get their thread local data setup correctly, which
>>> is needed for evacs (e.g. via oopDesc::cas_set_mark(..) )
>>> - the workers must not identify themselves as GC workers, otherwise
>>> OOM-evac protocol assumes that WBs are not needed. I implemented this by
>>> narrowing the condition in write-barrier to is_GC_task_thread() which
>>> should identify only actual GC workers, but not other threads like the
>>> safepoint workers.
>>>
>>> - I also propose to enable it by default. ZGC and G1 do it now, and not
>>> doing it basically guarantees this code to rot. I lowish number of
>>> threads seems to give the best bang for the buck.
>>>
>>> http://cr.openjdk.java.net/~rkennke/par-sp-workers/webrev.00/
>>>
>>> Testing: tier3_gc_shenandoah
>>>
>>> OK?
>>
>> Kinda OK. I wonder why doesn't it blow up the assert here?
>>
>> static void initialize_gclab(Thread* thread) {
>> assert (thread->is_Java_thread() || thread->is_Worker_thread(), "Only Java
>> and GC worker threads are allowed to get GCLABs");
>> data(thread)->_gclab = new PLAB(PLAB::min_size());
>> data(thread)->_gclab_size = 0;
>> }
>>
>
> Because those safepoint workers are worker threads.
Ah. Okay then.
-Aleksey
More information about the shenandoah-dev
mailing list