RFR: 8219613: Use NonJavaThread PtrQueues
zgu at redhat.com
zgu at redhat.com
Tue Feb 26 15:58:40 UTC 2019
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
Pleas let me know if I miss something.
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
> 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
> 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
> (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
> PtrQueue (_lock and _permanent members and associated behavior) is
> still needed too. I have more changes in progress to address that.
> gc/shared/barrierSet.cpp is in the webrev, but ended up not being
> I'll update copyrights before pushing.
> Shenandoah changes provided with the help of Aleksey Shipilev.
> mach5 tier1-3, hs-tier4-5
> jtreg: hotspot_gc_shenandoah
More information about the hotspot-gc-dev