New candidate JEP: 435: Asynchronous Stack Trace VM API

[David Holmes]

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