启用JVMTI *功能*以查询局部变量的开销 [英] Overhead of enabling JVMTI *capability* to query local variables

问题描述

我正在研究一种在JVM上运行的简单动态语言。其中一个必需的功能是：仅在抛出异常时，我需要能够在抛出异常时查询调用堆栈中所有帧的局部变量。标准Java或反射中不提供此功能。因此，我正在考虑以下想法：

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:

• 在C中编写一个简单的JVMTI共享对象


• 当在Java-land中抛出异常时，触发JVMTI函数


• JVMTI lib中的代码暂停抛出异常的Java线程，检查堆栈以提取本地，存储它们在某处可访问，并恢复Java线程

除了在这种情况下，JVMTI根本不会被使用。代码可能会运行几天而不会抛出异常，我希望它能像非启用JVMTI的代码一样快速运行。

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.

所以我的问题是：在主流JVM实现（即 Oracle）中，启用我需要的JVMTI功能的开销是多少？例如，这样做会禁用JIT吗？

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?

我对JVMTI能力的最佳猜测是：

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

• can_signal_thread
• can_get_source_file_name
• can_get_source_debug_extension
• can_access_local_variables

推荐答案

您提到的JVMTI功能不会阻止JIT编译。
但是某些优化将被禁用，例如逃逸分析和死亡本地消除。

此外，每个抛出的异常都会导致去优化（切换到解释器）。

尽管如此，整体性能开销应该可以忽略不计。

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.

这篇关于启用JVMTI *功能*以查询局部变量的开销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！