RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread

[Erik Österlund]

On Wed, 23 Sep 2020 06:32:14 GMT, Allan Gregersen <github.com+4676506+javeleon at openjdk.org> wrote:

> > > > I would like to hear answer to @dholmes-ora question in JBS:
> > > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?"
> > > 
> > > 
> > > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current
> > > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the
> > > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it
> > > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than
> > > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other
> > > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM?
> > 
> > 
> > 
> > 1. You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not
> > sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so
> > much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual
> > performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging
> > Truffle code alone, to be maintained separately. 2. We are talking about JVMTI, not JVMCI. iterateFrames is defined in
> > JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be
> > limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives
> > you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3. When you just read
> > locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something
> > we do, unless you change the locals, which you said you are not.  Please let me know if there is anything I missed. But
> > so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I
> > would like to better understand the problem domain before taking this further.
> 
> Thanks for your quick follow-up.
> 
>     1. It's not entirely made for the debugger use-case. For example in some guest languages we need this for implementing
>     Thread#getStackTrace or similar. In Espresso (Java as a Truffle guest language) we would need this also for
>     implementing part of the management API.
> 
>     2. I know that you suggested JVMTI and no JVMCI. Since I wasn't around when the decision to implement and include
>     iterateFrames into JVMCI was made, I'm unaware of the exact reasoning behind that decision. I was assuming that
>     whatever reason not to go with JVMTI back then would still hold true today. So say we wanted to adopt the JVMTI
>     approach now. Would the design be an in-process always on and in-process JVMTI agent? Would there be security
>     implications from such an approach leaving any VM running anything Truffle more vulnerable?
> 
>     3. No need for deoptimize anything when reading locals through JVMTI is good. Thanks for clarifying that.

So I understand it, you really have 2 cases:
1) Using the debugger
2) To support other APIs that need a stack trace

So if you use JVMTI for the debugging (like everybody else), that seems to be a solved problem.
As for the second use case, I hope you can use java.lang.StackWalker? It should give you all the info you could dream
of. If you can't use all classes in java.lang.* then I fear that you are in a lot of trouble using HotSpot in general.

-------------

PR: https://git.openjdk.java.net/jdk/pull/110