-
Bug
-
Resolution: Fixed
-
P2
-
13
-
b15
-
generic
-
generic
-
Not verified
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 toJDK-8219613 because before that change, non-Java-threads would simply use a shared SATB queue instead.
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
- blocks
-
JDK-8221435 Shenandoah should not mark through weak roots
-
- Resolved
-
- relates to
-
JDK-8221086 Shenandoah-specific workaround for JDK-8220671
-
- Closed
-
-
JDK-8221516 fatal error: Thread SATB queue has an unexpected active state
-
- Closed
-
-
JDK-8219613 Use NonJavaThread PtrQueues
-
- Resolved
-