[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