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

[Roman Kennke]

>>> I think the proposed fix for _just_ StringDedupThread is insufficient.
>>> I think there are other threads that could have similar races between
>>> on_thread_attach and being added to the NJT thread list. And it
>>> doesn't matter whether those threads touch oops or not. Even if they
>>> don't, the state verification done when the SATB transition is made
>>> can fail. (See SATBMarkQueueSet::verify_active_states.)
>>
>> Yeah I agree that this warrants a more generic solution. I am thinking about it. It is a tricky little bugger...
>>
>>> It might be sufficient to add a STS joiner around the on_thread_attach
>>> / add_to_the_list sequence in NJT::pre_run, with the joiner only
>>> active if invoked when not at a safepoint. That way we can still
>>> create threads during a safepoint that are needed in that safepoint
>>> (e.g. lazy allocation of worker threads). There are some possibly
>>> complicated cases to think about though, or maybe disallow somehow.
>>
>>
>> Checking for being at safepoint itself is racy if the thread is not participating in the safepointing protocol. On the other hand it might not be bad per se to block when at safepoint. As long as it doesn't hold back other threads that would not leave the safepoint as a result...
>>
>> I'll look a bit deeper into this and come back... on Monday ;-)
> 
> Yeah, this does look tricky.  I agree the activated STJ joiner on !safepoint is
> racy and might not work.  I will also think about it; I have one idea that seems
> promising, but I want to think about it some more, given that none of my
> previous ones seem to be panning out.
> 

I wonder if it would be sufficient to swap this:

  BarrierSet::barrier_set()->on_thread_attach(this);
  add_to_the_list();

to:

  add_to_the_list();
  BarrierSet::barrier_set()->on_thread_attach(this);

The former might get a problem if we've done on_thread attach before,
e.g., init-mark, and add_to_list after: the thread would end up not
being SATB active. The latter doesn't have this problem: it would either
add_to_the_list() in time (e.g. before init_mark) or take the right
action in on_thread_attach(). Right?

in post_run I believe it's already ordered correctly.

WDYT? Or am I missing something?

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190318/f1f363c7/signature.asc>