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

David Holmes david.holmes at oracle.com
Sun Mar 20 22:48:00 UTC 2022


On 18/03/2022 5:21 pm, Johannes Bechberger wrote:
> On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:
> 
>>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>>
>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Remove two unnecessary lines
> 
> This is not the point: It comes down to API design. If we use SafeFetch in os::is_first_C_frame (and thereby in frame::link_or_null) and not just in ASGCT, then it depends on when the other methods can be called. These methods are e.g. used whenever an error happens and a hs_err file is generated. We cannot guarantee that a JavaThread is always present there.

My comment was specifically in response to your statement:

 > I see AsyncGetCallTrace to assume the JavaThread very soon

But AGCT is only intended to ever be called on JavaThreads.

David

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


More information about the serviceability-dev mailing list