RFR: 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware [v2]

Daniel D.Daugherty dcubed at openjdk.java.net
Wed Feb 17 21:49:49 UTC 2021


On Wed, 17 Feb 2021 06:53:20 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:
>> 
>>   Address coleenp CR0 comments.
>
> src/hotspot/share/compiler/compileBroker.cpp line 1008:
> 
>> 1006:       if (TraceCompilerThreads) {
>> 1007:         ResourceMark rm;
>> 1008:         tty->print_cr("Added initial compiler thread %s", ct->get_thread_name());
> 
> This code seems potentially broken both before and after this change. If the ct thread is protected already (by current call chain) you don't need the lock, if it isn't protected then you can't safely call get_thread_name() on it without first ensuring it is still a valid reference.

Ouch! You are correct that any time after the make_thread() call,
the newly created JavaThread could run and exit quickly. In the
baseline code, the Threads_lock grab only keeps 'ct' from exiting
while the lock is held. It doesn't help if 'ct' exited before the lock
was grabbed.

I'm not sure why you would think that 'ct' could be protected by
the current call chain. Of course, I could be missing something.

I'm going to see if I can do something here with a TLH.

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

PR: https://git.openjdk.java.net/jdk/pull/2535


More information about the serviceability-dev mailing list