[jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2]

[Daniel D. Daugherty]

On Thu, 30 Jun 2022 03:12:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dholmes-ora - I'm very glad that I resisted putting the check in `threadObj()`
>> when I made the changes for:
>> 
>> [JDK-8288139](https://bugs.openjdk.org/browse/JDK-8288139) JavaThread touches oop after GC barrier is detached
>> 
>> The review for that PR took too long and clearly this discussion would have made
>> it take longer. JDK-8288139 is fixed and Zhengyu can make progress on his issue.
>> 
>> I don't see a good way to make forward progress in this PR. It doesn't look like you
>> and I will reach a solution that's acceptable to both of us.
>> 
>> The only good news is that my many rounds of testing on this fix have convinced me
>> threadObj() is not being abused in the current code base except for the very narrow
>> case where we crash (for whatever reason) after the GC barrier is detached. Should
>> the GC team chose to put in an appropriate trap in their code that catches a thread
>> accessing an oop after the GC barrier is detached, then threadObj() will be automatically
>> sanity checked by that code.
>> 
>> Thanks for your time in doing several rounds of review.
>
>> I'm very glad that I resisted putting the check in threadObj() when I made the changes for ...
> 
> The problem has not been (until now) what you put in threadObj but the other checks you decided to put in.
> 
> But now the issue has been raised, any code that can be executed in the context of a signal handler must use `Thread::current_or_null_safe()`. I don't know if the sharedRuntime code falls into that category but a call to `threadObj()` certainly can.
> 
> Sorry this has not been smooth sailing.

@dholmes-ora - please re-review when you get the chance. I've started a
new round of testing in Mach5.

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

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