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

Roman Kennke rkennke at redhat.com
Mon Mar 18 11:39:15 UTC 2019


>>> 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.

Ok, I think I have a fix candidate:
http://cr.openjdk.java.net/~rkennke/JDK-8220671/webrev.05/

I added a method BS::needs_sts_sync_on_attach_detach() so that GCs can
avoid using this additional synchronization when they are not
implementing attach/detach or not using STS.

This passes tier1 and the offending Shenandoah testcase locally. I will
push it through jdk/submit.

What do you think? Can I get reviews on this? Or do you have something
better in mind?

Thanks,
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.java.net/pipermail/hotspot-gc-dev/attachments/20190318/7d91127d/signature.asc>


More information about the hotspot-gc-dev mailing list