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

[Mandy Chung]

On Thu, 24 Sep 2020 16:39:10 GMT, Allan Gregersen <github.com+4676506+javeleon at openjdk.org> wrote:

>>> >The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set,
>>> >and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes
>>> >this variable and presumably plays by the same rules.
>>> 
>>> 
>>> 
>>> A few questions pops into my mind:
>>> 
>>> 
>>> 
>>> 1. What is the performance implications on setting _jvmti_can_access_local_variables capability? More specifically,
>>> does this capability kill off escape analysis for a GraalVM?
>> 
>> Yes, it will disable escape analysis... when you are running in the debugger.
>> 
>>> 2. When we have multiple Truffle contexts running, including but not limited to different guest languages, can we make
>>> sure that escape analysis is only switched off on very specific parts of the host system with this set and can we
>>> enable/disable this capability on the fly?
>> 
>> Why do you care to isolate the performance cost of debugging so tightly? Are you trying to enable some kind of use case
>> where you are mixing development and production execution in the same JVM, so some code can run at optimal performance
>> in production, driving a heavy production workload, while someone is single stepping other buggy development code in
>> the debugger?
>
> As a result of a useful offline discussion with @fisk, we’ve decided to pause effort on this PR and investigate what it
> would take to enhance the StackWalker API to serve all the Truffle use cases. Stay tuned for updates…

I suggest to send out the proposed extension to `StackWalker` API after the initial investigation for discussion.    A
discussion on the proposed API change would be useful before sending out a PR for code review.  Thanks.

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

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