RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread
Erik Österlund
eosterlund at openjdk.java.net
Thu Sep 24 12:22:22 UTC 2020
On Thu, 24 Sep 2020 12:00:22 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?
-------------
PR: https://git.openjdk.java.net/jdk/pull/110
More information about the hotspot-compiler-dev
mailing list