RFR: JDK-8220671: Initialization race for non-JavaThread PtrQueues

Kim Barrett kim.barrett at oracle.com
Tue Mar 19 02:50:06 UTC 2019

> On Mar 18, 2019, at 6:35 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> (3) I think the reason on_thread_attach preceeds adding to the list is
> to prevent SATB state verification from failing.  (Except that doesn't
> quite work because of this new-found race.)  So another approach is to
> reverse the order and address the verification failure directly.  Add
> another "unitialized" initial state.  SATB activation verification
> treats "uninitialized" as okay, and the activation state change
> unconditionally updates the thread state.  For on_thread_attach,
> conditionally set the thread state when the old state is
> "uninitialized", using cmpxchg to address the potential race between a
> global change and the initialization.  I think something similar could
> be done for ZGC.  But this is pretty tightly coupled to properties of
> the state being cached.

I started exploring down this path, and it looks plausible.  But it will have a
somewhat messy merge with  JDK-8220240, which is waiting for a second

More information about the hotspot-gc-dev mailing list