RFR: 8288139: JavaThread touches oop after GC barrier is detached

[Daniel D. Daugherty]

On Thu, 16 Jun 2022 12:45:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The placement in SharedRuntime::get_java_tid() is because that is the failure
>> mode that this bug is about. My next stress testing experiment will be to put
>> a similar guarantee() in threadObj(), but I expect there to be more fan-out
>> from that placement.
>> 
>> This fix is tightly focued on the bug as it is reported because I plan to fix
>> it in JDK19.
>
> Yeah ... hmmm ... threadObj is still the better place for any safety check ... arguably it should be even deeper in OopHandle.
> 
> I'm not sure what fanout you are concerned about. If we find there are other invalid oop accesses then we would want to fix them in 19 - no?

I want to fix this bug in JDK19 since it is a blocker for @zhengyu123. I want to
keep this fix small and focused on the exact crash associated with the bug.

Yes, threadObj() or deeper is a better place. No argument, but I plan to do that
as a new hunt and I expect there to be many problems and I don't want to hold
up this fix for additional hunting. If I find more issues, then we'll determine how
to get them fixed in JDK19.

-------------

PR: https://git.openjdk.org/jdk19/pull/21