RFR: Only Java and GC worker threads should get GCLABs

[Roman Kennke]

Am 31.08.2018 um 16:27 schrieb Aleksey Shipilev:
> On 08/31/2018 04:02 PM, Aleksey Shipilev wrote:
>> This seems to be the bug that we are chasing now in sh/jdk. ShenandoahControlThread accidentally got
>> the GCLAB, but never retired it. When traversal-precleaning started, it walked some unmarked
>> objects, evacuating them, which happened in the ShControlThread context. Which means we have
>> allocated something in GCLAB we don't otherwise know about. And the whole thing crashes if we get to
>> recycle the region holding that GCLAB before it retires.
>>
>> There are two possible fixes: let GCLAB retirement code know about ShControlThread, or make
>> ShControlThread go via shared allocs all the time, like other non-Java threads do. I think the
>> second option is better, because doing the GCLAB retirement from the ShControlThread might be prone
>> to other errors (e.g. deadlocks). We intended that only Java threads and GC worker threads have
>> GCLABs to simplify GCLAB tracking, but this is not true it current code, see below.
> 
> (changing subject)
> 
> tier3_gc_shenandoah trips on new asserts, because StrDedupThread is _also_ ConcurrentGCThread! And
> we walk it in gc_threads_do. The way out is to explicitly touch only the GC workers on GCLAB paths:
>   http://cr.openjdk.java.net/~shade/shenandoah/gclab-only-special/webrev.01/
> 
> Testing: failing tests, tier3_gc_shenandoah (running)
> 
> -Aleksey
> 


Yup.