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

[Kim Barrett]

> On Mar 16, 2019, at 5:18 PM, Roman Kennke <rkennke at redhat.com> wrote:
>> 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.