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

[Allan Gregersen]

On Tue, 22 Sep 2020 06:42:00 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?

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

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