RFR: Only Java and GC worker threads should get GCLABs

[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