>> Hi there, >> >> following up with discussions that took place between various folks from >> Oracle, Amazon, SAP and Datadog, I would like to propose two >> proof-of-concepts for a JVMTI async stack-walker API. Those are by no means >> complete implementations, but are meant to serve as a basis for further >> discussions. > > I see both PoCs propose standard APIs. JVMTI is Java SE and VM independent so > would be problematic to have normative reference to "JFR" in the spec. Once > you converge on a direction then it would be interesting to see if it could > be exposed using the JVMTI extension mechanism as that would give you > flexibility to make available JDK-specific features > >>
Hi Alan, thanks for offering your perspective. I have changed both POCs (and the corresponding example code) to implement as JVMTI extensions - I didn't even know that such a mechanism exists. They currently still use a capability to set up what they need (and that's in the public API unfortunately), I am wondering if there is something similar for JVMTI extensions? Worst case, I would perhaps add another extension function to initialize things. Also, is there any way for consumers of the API to get some documentation? The second POC uses callbacks, and I suppose it might be useful for a prospective user of the API to know the arguments etc of those. As it currently is, the callback functions are basically black boxes, reported by the extension mechanism as void* - the user of the API would have to know what functions exactly to pass as callbacks. (Worst case, I guess it could be described in a blog-post or so.) Cheers, Roman
