[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: New candidate JEP: 435: Asynchronous Stack Trace VM API
From:       "Bechberger, Johannes" <johannes.bechberger () sap ! com>
Date:       2022-12-22 8:24:05
Message-ID: 2B233D2E-BDF7-46BC-815B-D14C0F060189 () sap ! com
[Download RAW message or body]

> 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-retn@openjdk.org on behalf of david.holmes@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%2F \
jeps%2F435&data=05%7C01%7Cjohannes.bechberger%40sap.com%7C0d2457dd80474937e97208dae3e2 \
39ab%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638072858015327140%7CUnknown%7CTWFpb \
GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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


[prev in list] [next in list] [prev in thread] [next in thread]