RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v7]

[Thomas Stuefe]

On Mon, 21 Mar 2022 12:44:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove two unnecessary lines
>
> I'm currently implementing Andrews proposal for a static safefetch (https://github.com/openjdk/jdk/pull/7865, still in draft, but almost done). That will be more generic solution since we don't have to deal with thread wx state at all. That's why we closed this PR.

> The conversation here is some what hard to follow. I do see that "foreign threads" was mentioned by @tstuefe in the context of AGCT but I have to assume he misspoke there (assuming a foreign thread is one not attached to the VM) as AGCT only works for attached JavaThreads. The signal handler that will call AGCT has to be prepared to find any kind of thread in any state, but AGCT should only be called on the right kinds of thread in the right state.

Sure, AGCT can be limited to VM threads - or maybe already is. But tracking non-VM threads could be a valid use case. 

We have downstream in the SapMachine a facility where we track callstacks from malloc sites - independently from NMT or the VM. With the explicit purpose of catching mallocs from non-VM threads too. For collecting the stack trace, we use some VM utilities, SafeFetch among them. That is a very useful facility. I could argue a similar case for the Async Profiler: why should profiling be limited to Java threads? In the end, if it eats performance, it hurts, regardless whether its a java thread or a non-VM-attached thread. Could be a concurrent native thread burning CPU, why would that not be interesting.

Our concern was with SafeFetch, and AGCT is only one example. SafeFetch should be as safe as possible. Error reporting alone is a sufficient reason.

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

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