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

Daniel D. Daugherty dcubed at openjdk.org
Tue Jun 28 13:45:54 UTC 2022


On Mon, 27 Jun 2022 22:46:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   dholmes CR - check if current thread's oop access is safe.
>
> src/hotspot/share/runtime/thread.cpp line 2151:
> 
>> 2149:   st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen));
>> 2150:   Thread* current = Thread::current_or_null();
>> 2151:   if (current != nullptr && (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe())) {
> 
> Just realized, we can't have a null current thread if we are calling this as that is checked at a higher level. But we should be using `current_or_null_safe()` here as we could be in a signal-handling context.

I used `Thread::current_or_null()` just to make the code more bullet proof. In all of
my testing I never ran into a case where `Thread::current()` returned `nullptr`.
I'm going to switch back to `Thread::current()` and remove the extra handling for
the `current == nullptr` case.

> src/hotspot/share/runtime/thread.cpp line 2220:
> 
>> 2218:   if (current == nullptr) {
>> 2219:     // Current thread is not attached so it can't safely determine this
>> 2220:     // JavaThread's name so use the default thread name.
> 
> This should not be possible, but again `current_or_null_safe` should be used.
> 
> Though this code is used a lot in normal operation so the additional overhead of this is more significant than the print_on_error case.
> 
> I think this check should be moved to the caller if  needed (ie the print_on_error code), as in normal use it is not possible to fail this check.

I'm going to switch back to `Thread::current()` and remove the extra handling for
the `current == nullptr` case.

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

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


More information about the hotspot-runtime-dev mailing list