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

[Daniel D. Daugherty]

On Mon, 27 Jun 2022 22:50:48 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.
>
> Sorry Dan have to revoke my approval. There are still some issues here that need fixing and I don't like the impact on the code.

@dholmes-ora - Thanks for the re-review. I'm going to update the fix again and
switch back to using `Thread::current()` instead of `Thread::current_or_null()`.

The reason that this particular handling of a secondary failure is important is
that a secondary failure in printing the name of the failing thread will prevent
entries for following threads from being printed in the thread list in the hs_err_pid
file.

Here's an example to show placement:

Java Threads: ( => current thread )
  0x00007fd64d808a00 JavaThread "Unknown thread" [_thread_blocked, id=7427, stack(0x0000700003c18000,0x0000700003d18000)]
  0x00007fd64e80d400 JavaThread "Unknown thread" [_thread_blocked, id=43011, stack(0x0000700004433000,0x0000700004533000)]
  0x00007fd64e80e200 JavaThread "Unknown thread" [_thread_blocked, id=42755, stack(0x0000700004536000,0x0000700004636000)]
  0x00007fd64e80e800 JavaThread "Unknown thread" [_thread_blocked, id=42243, stack(0x0000700004639000,0x0000700004739000)]
  0x00007fd64e80ee00 JavaThread "Unknown thread" [_thread_blocked, id=22787, stack(0x000070000473c000,0x000070000483c000)]
  0x00007fd64e80f400 JavaThread "Unknown thread" [_thread_blocked, id=41731, stack(0x000070000483f000,0x000070000493f000)]
  0x00007fd64e81e800 JavaThread "Unknown thread" [_thread_blocked, id=41219, stack(0x0000700004942000,0x0000700004a42000)]
  0x00007fd64e81ee00 JavaThread "Unknown thread" [_thread_blocked, id=23299, stack(0x0000700004a45000,0x0000700004b45000)]
  0x00007fd650819000 JavaThread "Unknown thread" [_thread_blocked, id=40451, stack(0x0000700004b48000,0x0000700004c48000)]
  0x00007fd64e851400 JavaThread "Unknown thread" [_thread_blocked, id=23811, stack(0x0000700004c4b000,0x0000700004d4b000)]
  0x00007fd64d84e200 JavaThread "Unknown thread" [_thread_blocked, id=24067, stack(0x0000700004e51000,0x0000700004f51000)]
  0x00007fd64e81c600 JavaThread "Unknown thread" [_thread_blocked, id=39171, stack(0x0000700004f54000,0x0000700005054000)] _threads_hazard_ptr=0x00007fd64e0041b0
  0x00007fd64d80d000 JavaThread "Unknown thread" [_thread_blocked, id=38915, stack(0x0000700005057000,0x0000700005157000)]
=>0x00007fd650812000 JavaThread "<no-name - current JavaThread has exited>" [_thread_in_vm, id=24835, stack(0x000070000515a000,0x000070000525a000)]


The entry prefixed with "=>" is the crashing thread that is past the GC barrier
detach point. In this example, it happens to be the last thread in the `Java Threads:
( => current thread )` section of the hs_err_pid file. However, if the failing thread
happened to be earlier in the list and we didn't prevent the secondary error, then
we would be missing entries from the section.

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

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