> 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.
You're right, "safe" is the wrong word. I meant "stable" in the sense, that it
is unlikely to crash your JVM. This is ensured by testing the implementation
with fuzzing and stability tests.
> 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?
Regarding the key differences: It is built with stability as a major concern,
its implementation, therefore, contains more safety checks and is tested
properly.
Regards
Johannes
> This relationship/dependency on JVM/TI is not mentioned in the JEP as
far as I can see.
Good catch, I'll amend the JEP to mention the dependency: "You have to trigger
the allocation of jmethodIDs outside the signal handler."
On 22.12.22, 07:03, "serviceability-dev on behalf of David Holmes"
<serviceability-dev-r...@openjdk.org on behalf of david.hol...@oracle.com>
wrote:
On 3/11/2022 4:36 am, Mark Reinhold wrote:
>
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F435&data=05%7C01%7Cjohannes.bechberger%40sap.com%7C0d2457dd80474937e97208dae3e239ab%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638072858015327140%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NIj3UlDXYvWFlrhypC1meAkB16FFbMtZPx%2BBOPOnjgs%3D&reserved=0
>
> 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
