Hi Xin, > Thanks. Now I understand the roadmap better. We can only pick one of > those two JEPs, right?
No, but... > JEP Draft: Native Profiler Hook for Unbiased Stack Traces > (Experimental) (https://openjdk.org/jeps/8380294) This is the JEP that has the most agreement so far and is likely to land first, hopefully in JDK 28. > JEP Draft: Unbiased Stack-Walk JVMTI extension API > (https://openjdk.org/jeps/8381322) That would be an extension of the JEP 8380294. It is not as mature and is not certain to land at all, but it would be the full AsyncGetCallTrace replacement that JEP 8380294 is not. > They use the exact same JVMTI name. Given that > https://github.com/openjdk/jdk/pull/31059 is a formal PR, do we still > have room for the second one? One should be RequestJFRStackTrace and the other should be RequestStackTrace. Notice that I have just posted a prototype for the 2nd JEP today: https://github.com/openjdk/jdk/pull/33629 It turned out different than I first had in mind. No callbacks, as they are somewhat unsafe to call from certain places. > > - We will *not* make it compatible with ASGCT, at least not directly. ASGCT > > is inherently not made for the sort of asynchronousness that we need. What > > would perhaps work for you is the JVMTI-only proposal: > > https://openjdk.org/jeps/8381322, that would allow you to use JVMTI > > callback to build your own ASGCT_CallTrace structure if you really need > > that. > > Yes, it works for me. The prototype I mentioned before builds on that > PR. I made a few tweaks. > 1. ASGCT_CallTrace is not allocated externally. I use alloca to > prepare a buffer for all pending requests in report_thread(). > 2. Transitioning to native in those callbacks is expensive. I made a > pact that callbacks are JFR_LEAF and waive your VM2Native. > 3. Make your NativeStackWalkerThread a JavaThread to enable Java calls. > > Your callback framework utilizes vtable to dispatch JFR or custom > stackwalkers. > Now there are only two subclasses. I plan to add a new for > ASGCT_CallTrace compatibility layer after PR#31059 is merged. Ewww, the intention for the callbacks was *not* to be any sort of public API. > Do you consider an alternative way to support polymorphism? > Like a template parameter or member data in JfrStackWalkerCallback? > This unfortunately requires more invasive changes. I guess you have > considered them. No, not really. Custom stack-walkers is not something that we intend to provide, sorry. > > - Extending the stack-walker to handle anything Kotlin-specific is most > > likely not going to happen. I am not familiar with how Kotlin works, but > > again, perhaps the JVMTI callbacks approach would work for you? > > This extends your JfrStackWalkerVframeStream. It is orthogonal to > JVMTI callbacks. > Just like vframe for inlined compiled methods, we generate some > logical frames by traversing the linked list of Continuation objects. I don't know enough about Kotlin Continuations to provide useful guidance how to implement support for it, or which sort of API would be useful for you to do that. But I don't think that opening up any VM internals like the stackwalker would be feasible. If there is any way to detect, walk, report Kotlin continuation frames in a generic way, i.e. such that it does not end up Kotlin specific, then we may consider it, but I don't think we should allow agents to mess with JVM internals in such a way. In-fact, the whole point of the JEPs is to allow profilers to do their work *without* messing with JVM internals in dangerous ways... so let's think about how to do it safely and in a sane way. Cheers, Roman
