RFR: 8219613: Use NonJavaThread PtrQueues

[zgu at redhat.com]

Hi Kim,

Probably not directly relates to this RFR, but I see a couple of issues
with this BarrierSet::on_thread_xxx mechanism.

1) When creating worker thread, it is added to WorkGang's thread first,
and on_thread_attach() is not called until worker thread starts to run.
If I use on_thread_attach() to initialize something (e.g. gclab), I may
hit this timing gap, because WorkGang::threads_do() may hit
uninitialized data (e.g. gclab)

2) The alternative is to use on_thread_create(), but it is called from
Thread's constructor, therefore, I can not tell what kind of thread it
is.

Pleas let me know if I miss something.

Thanks,

-Zhengyu

On Mon, 2019-02-25 at 22:27 -0500, Kim Barrett wrote:
> Please review this change to G1 and Shenandoah to use the already
> extent thread-local PtrQueues in NonJavaThreads, rather than using
> shared queues that require locking.
> 
> This is a step toward addressing JDK-8209974, JDK-8173211, and
> JDK-8170020.
> 
> There are several parts to the change:
> 
> The existing BarrierSet::on_thread_(attach|detach) functions get
> extended to apply to and be called for all threads, not just Java
> threads.  A few implementations need to limit some of their behavior
> to Java threads, but others can just apply most or all of their
> existing behavior to non-Java threads too.  This includes ZGC.
> 
> Most operations involving shared queues are now applied to the
> corresponding thread-local queue, irrespective of whether the thread
> is a Java thread or not.  Previously, a non-Java thread had to use
> the
> appropriate shared queue.
> 
> Various iterations over threads get expanded to apply to all threads,
> rather than only Java threads.
> 
> This change eliminates the single shared SATB queue and the
> associated
> (access-rank) lock.  It does not eliminate the shared dirty card
> queues, as there is one use that can't be switched to using the
> thread-local queue.  Because of that, the support for shared queues
> in
> PtrQueue (_lock and _permanent members and associated behavior) is
> still needed too.  I have more changes in progress to address that.
> 
> https://bugs.openjdk.java.net/browse/JDK-8219613
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8219613/open.01/
> 
> gc/shared/barrierSet.cpp is in the webrev, but ended up not being
> changed.
> 
> I'll update copyrights before pushing.
> 
> Shenandoah changes provided with the help of Aleksey Shipilev.
> 
> Testing:
> mach5 tier1-3, hs-tier4-5
> jtreg: hotspot_gc_shenandoah
>