RFR: 8288497: add support for JavaThread::is_gc_barrier_detached()
Erik Österlund
eosterlund at openjdk.java.net
Thu Jun 16 07:20:07 UTC 2022
On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows
> us to add checks to detect failures like:
>
> JDK-8288139 JavaThread touches oop after GC barrier is detached
> https://bugs.openjdk.org/browse/JDK-8288139
>
> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8].
> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running.
I have also been bitten before by oops being touched at the boundaries of the thread life cycle, so I understand why we would want to be more precise about modelling this in the thread life cycle. The only thing I don't understand with the patch is why there are two alternative state machines now. One that goes through the new state and one that does not go through the new state. There might be a good reason for that, but I would like to understand why that is. And probably have that written in a comment where the two state machines are described.
-------------
PR: https://git.openjdk.org/jdk19/pull/20
More information about the hotspot-runtime-dev
mailing list