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

[Erik Österlund]

On Tue, 22 Sep 2020 09:17:08 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.

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

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