RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
Johannes Bechberger
duke at openjdk.java.net
Tue May 17 12:56:00 UTC 2022
On Tue, 17 May 2022 12:50:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:
>>
>>
>> thread->set_in_asgct(true);
>> <stuff>
>> thread->set_in_asgct(false);
>>
>> with
>>
>>
>> ASGCTMark mark(thread);
>> <stuff>
>>
>> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.
>>
>> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.
>
> @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here.
It would be interesting to see if it this ASGCT flag is useful in JFR, i.e. if JFR suffers potentially from the same problem. There would then be two additional places for setting this flag.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8549
More information about the serviceability-dev
mailing list