Hi Mark, what is the process now going forward?
Regards Johannes From: Bechberger, Johannes <johannes.bechber...@sap.com> Date: Tuesday, 11. October 2022 at 10:18 To: Mark Reinhold <mark.reinh...@oracle.com> Cc: andrei.pan...@gmail.com <andrei.pan...@gmail.com>, Langer, Christoph <christoph.lan...@sap.com>, jaroslav.bacho...@datadoghq.com <jaroslav.bacho...@datadoghq.com>, serviceability-dev@openjdk.org <serviceability-dev@openjdk.org> Subject: Re: Submitted JEP: Asynchronous Stack Trace VM API Thanks for your comments. I incorporated them in the updated version of the JEP and updated all related repositories that now are implemented based on current JDK20 head and async-profiler head. The implementation of the JEP now resides in the sandbox repository too. Regards Johannes From: Mark Reinhold <mark.reinh...@oracle.com> Date: Wednesday, 5. October 2022 at 00:05 To: Bechberger, Johannes <johannes.bechber...@sap.com> Cc: andrei.pan...@gmail.com <andrei.pan...@gmail.com>, Langer, Christoph <christoph.lan...@sap.com>, jaroslav.bacho...@datadoghq.com <jaroslav.bacho...@datadoghq.com>, serviceability-dev@openjdk.org <serviceability-dev@openjdk.org> Subject: Submitted JEP: Asynchronous Stack Trace VM API https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F8284289&data=05%7C01%7Cjohannes.bechberger%40sap.com%7Ce4bb4293c6dd4dc6112f08daa65490bf%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638005179392019024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OkizIAXRzVPb3lbfugQn%2BFwdQdGN7YBO7lDNrEDrj2M%3D&reserved=0 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
