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

[Allan Gregersen]

On Thu, 24 Sep 2020 12:19:54 GMT, Erik Österlund <eosterlund 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?
>> 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?
>
>> >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…

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

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