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
