JDK-8220671 : Initialization race for non-JavaThread PtrQueues
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-03-14
  • Updated: 2020-01-14
  • Resolved: 2019-04-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b15Fixed
Related Reports
Blocks :  
JDK-8221435 - Shenandoah should not mark through weak roots
Relates :  
JDK-8221086 - Shenandoah-specific workaround for JDK-8220671
Relates :  
JDK-8219613 - Use NonJavaThread PtrQueues
Relates :  
JDK-8221516 - fatal error: Thread SATB queue has an unexpected active state
Description
In Shenandoah testing we discovered an initialization race: A non-Java GC thread (we have observed it on the StringDedupThread) may be initialized concurrently while Java and GC are already up an running, but not (yet) participate in safepointing.

BS::on_thread_attach() usually does propagate global GC state to thread-local GC state, in this case the SATB active flag.

When doing this concurrently, while not participating in safepointing, this may propagate the wrong state, and subsequently lead to heap corruption (e.g. because we missed some SATB updates).

This is related to JDK-8219613 because before that change, non-Java-threads would simply use a shared SATB queue instead.