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

[Allan Gregersen]

On Tue, 22 Sep 2020 10:51:16 GMT, Erik Österlund <eosterlund 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.

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

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