Submitted JEP: Asynchronous Stack Trace VM API

[Mark Reinhold]

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