Submitted JEP: Asynchronous Stack Trace VM API

[Lindenmaier, Goetz]

Hi,

I appreciate a lot the new name, especially replacing call trace by 
stack trace, because it is stack traces that are handled by the API.
Maybe adding "native" might be a good idea, because it can also 
handle native frames?  I think this is a distinguishing feature
of this API.

Best regards,
  Goetz.

> -----Original Message-----
> From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of
> Mark Reinhold
> Sent: Wednesday, October 5, 2022 12:06 AM
> To: Bechberger, Johannes <johannes.bechberger at sap.com>
> Cc: andrei.pangin at gmail.com; Langer, Christoph
> <christoph.langer at sap.com>; jaroslav.bachorik at datadoghq.com;
> serviceability-dev at openjdk.org
> Subject: Submitted JEP: Asynchronous Stack Trace VM API
> 
> https://openjdk.org/jeps/8284289
> 
> Thanks for this submission.
> 
> To start, I've shortened the title of the JEP to something that's
> hopefully more recognizable.
> 
> I won't comment here on the technical merits of the draft, though I may
> do so elsewhere.  For now, some editorial and procedural questions and
> suggestions:
> 
>   - In the Summary you say that the API will be "secure."  How will it
>     be any more secure than the existing `AsyncGetCallTrace` API?  The
>     JEP text does not say.
> 
>   - One of your goals is to "Support asynchronous usage as well as
>     calling the API from signal handlers."  Isn't calling the API from a
>     signal handler a special case of asynchronous usage?
> 
>   - You state that "The new API shall not be recommended for production
>     usage."  If it's not for production usage then:
> 
>       - Will using the API require -XX:+UnlockExperimentalVMOptions?
> 
>       - What does the use of the word "supported" in the Summary
>         actually mean?
> 
>   - You note that one of the flaws of the existing API is that it's not
>     exported in any header.  Via which header file will this new API be
>     exported?
> 
>   - For IP clarity, please make your prototype implementation available
>     in an OpenJDK repository, for example the JDK Sandbox repository.
> 
>   - In the Testing section, you say that "Unifying the existing
>     profiling-related stack walking code allows for testing it more
>     efficiently by combining the existing tests."  This JEP no longer
>     proposes such a unification, so please adjust this text.
> 
> - Mark