什么是HotSpot JIT中的去反射优化？它是如何实现的？ [英] What is a de-reflection optimization in HotSpot JIT and how does it implemented?

问题描述

观看 java.lang.reflect.Method 委托调用。

生成动态字节码的方法要快得多，因为它

• 不会受到JNI开销的影响;


• 每次都不需要解析方法签名，因为通过Reflection调用的每个方法都有自己唯一的MethodAccessor;


• 可以进一步优化，例如这些MethodAccessors可以受益于所有常规JIT优化，如内联，常量传播，自动装箱消除等。

注意，此优化主要是实现的在 Java代码中没有JVM帮助。 HotSpot VM唯一可以实现此优化的功能是跳过此类生成的MethodAccessors的字节码验证。否则，验证者不会允许，例如，调用私有方法。

Watching Towards a Universal VM presentation, I studied this slide, which lists all the optimisations that HotSpot JIT does:

In the language-specific techniques section there is a de-reflection. I tried to find some information about it accross the Internet, but failed. I understood that this optimization eliminates reflection costs in some way, but I'm interested in details. Can someone clarify this, or give some useful links?

解决方案

Yes, there is an optimization to reduce Reflection costs, though it is implemented mostly in Class Library rather than in JVM.

Before Java 1.4 Method.invoke worked through a JNI call to VM runtime. Each invocation required at least two transitions from Java to Native and back to Java. The VM runtime parsed a method signature, verified that types of passed arguments were correct, performed boxing/unboxing and constructed a new Java frame for a called method. All that was rather slow.

Since Java 1.4 Method.invoke uses dynamic bytecode generation if a method is called more than 15 times (configurable via sun.reflect.inflationThreshold system property). A special Java class responsible for calling the given particular method is built in run-time. This class implements sun.reflect.MethodAccessor which java.lang.reflect.Method delegates calls to.

The approach with dynamic bytecode generation is much faster since it

• does not suffer from JNI overhead;
• does not need to parse method signature each time, because each method invoked via Reflection has its own unique MethodAccessor;
• can be further optimized, e.g. these MethodAccessors can benefit from all regular JIT optimizations like inlining, constant propagation, autoboxing elimination etc.

Note, that this optimization is implemented mostly in Java code without JVM assistance. The only thing HotSpot VM does to make this optimization possible - is skipping bytecode verification for such generated MethodAccessors. Otherwise the verifier would not allow, for example, to call private methods.

这篇关于什么是HotSpot JIT中的去反射优化？它是如何实现的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！