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 <[email protected]> On Behalf Of > Mark Reinhold > Sent: Wednesday, October 5, 2022 12:06 AM > To: Bechberger, Johannes <[email protected]> > Cc: [email protected]; Langer, Christoph > <[email protected]>; [email protected]; > [email protected] > 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
