On 3/11/2022 4:36 am, Mark Reinhold wrote:
https://openjdk.org/jeps/435
Summary: Define an efficient and reliable API to collect stack traces
asynchronously and include information on both Java and native stack
frames.
There has been some commentary on this in the JBS issue and some
previous discussion on the mailing list(s), which has left me a little
unclear on some of the details.
From the JEP:
> Calling this API from a signal handler is safe,
What is the definition of "safe" you are using in a signal handling
context? The code is certainly executing a ton of stuff not known to be
async-signal-safe.
> and the new
> implementation will be at least as stable as AsyncGetCallTrace or the
> JFR stack walking code.
If this is to be a supported API then it has to be more stable than the
existing unsupported API. How is that stability achieved? What are the
key differences with AGCT that make this more stable?
Looking at the code I see in profile.h
// This function must only be called when JVM/TI
// CLASS_LOAD events have been enabled since agent startup. The enabled
// event will cause the jmethodIDs to be allocated at class load time.
// The jmethodIDs cannot be allocated in a signal handler because locks
// cannot be grabbed in a signal handler safely.
This relationship/dependency on JVM/TI is not mentioned in the JEP as
far as I can see.
Thanks,
David
