Overhead of enabling JVMTI *capability* to query local variables

问题

I'm working on a simple dynamic language that runs on the JVM. One of the required capabilities is this: only when an exception is thrown, I need to be able to query the local variables for all frames in the call stack at the time the exception is thrown. This capability is not available in standard Java or reflection. Thus I'm looking at the following idea:

• Write a simple JVMTI shared object in C
• When an exception gets thrown in Java-land, trigger a JVMTI function
• Code in the JVMTI lib suspends the Java thread that threw the exception, inspects the stack to pull out the locals, stores them somewhere accessible, and resumes the Java thread

Other than in this one scenario, JVMTI would not be used at all. Code could potentially run for days without throwing an exception and I would hope it would run as fast as non-JVMTI enabled code.

So my question is: in the mainstream JVM implementations (ie Oracle), what is the overhead of enabling the JVMTI features I need? For example, would doing so disable JIT'ing?

My best guess of the JVMTI "capabilities" I need is:

• can_signal_thread
• can_get_source_file_name
• can_get_source_debug_extension
• can_access_local_variables

回答1:

JVMTI capabilities you mentioned will not prevent from JIT compilation. However certain optimizations will be disabled, e.g. Escape Analysis and dead locals elimination.
Also every thrown exception will cause deoptimization (switching to interpreter).
Nevertheless, overall performance overhead should be negligible.

来源：https://stackoverflow.com/questions/24108591/overhead-of-enabling-jvmti-capability-to-query-local-variables