在JVM中实现invokevirtual [英] Implementation of invokevirtual in JVM

问题描述

我曾期望Java虚拟机将使用简单的查找表进行常规方法调用:该对象包含一个指向查找表的指针，该指针具有该类实现的所有方法(包括由超类实现的方法)的地址. ).一个特定的方法仅由该表中的索引表示. JVM在表中查找方法的地址，然后跳转到该地址.

I had expected that the Java Virtual Machine would use a simple lookup table for normal method invocations: The object contains a pointer to a lookup table with the addresses for all methods that the class implements (including the methods implemented by super-classes). A specific method is simply represented by an index into that table. The JVM looks up the address of the method in the table, and jumps to that address.

但是JVM规范指定了一个漫长而复杂的过程，用于在运行时查找正确的方法(请参见

But the JVM specification specifies a long and complex procedure for looking up the correct method at run-time (see the official spec):

无符号的indexbyte1和indexbyte2用于构造索引 进入当前类的运行时常量池中(该类必须是一个 对方法的符号引用，该方法给出名称和描述符 方法的符号以及对其中的类的符号引用 该方法将被发现.命名方法已解决. [...] 然后 invokevirtual指令的执行过程如下.

The unsigned indexbyte1 and indexbyte2 are used to construct an index into the run-time constant pool of the current class [which] must be a symbolic reference to a method , which gives the name and descriptor of the method as well as a symbolic reference to the class in which the method is to be found. The named method is resolved. [...] then the invokevirtual instruction proceeds as follows.

如果C包含重写的实例方法m的声明 (第5.4.5节)已解析的方法，则m是要调用的方法，并且 查找过程终止.

If C contains a declaration for an instance method m that overrides (§5.4.5) the resolved method, then m is the method to be invoked, and the lookup procedure terminates.

否则，如果C具有超类，则相同的查找过程为 使用C的直接超类递归执行；该方法 被调用是此查找的递归调用的结果 程序.

Otherwise, if C has a superclass, this same lookup procedure is performed recursively using the direct superclass of C; the method to be invoked is the result of the recursive invocation of this lookup procedure.

我希望这个复杂而漫长的过程需要很长时间.由于此操作是针对每个常规方法调用完成的，因此基于JVM的程序几乎所有时间都将花费在此过程中.

I would expect this complex and long procedure to take a long time. Because it is done for every normal method call, almost all time for JVM based programs would be spent in this procedure.

这真的是在真实(Oracle)JVM中实现的方式吗?还是JVM对查询表执行JIT编译类型?是否有具体的JVM如何实际实现此目的的描述?

Is this really how it is implemented in the real (Oracle) JVM? Or does the JVM do a JIT type of compilation to a lookup table? Is there a description of how the concrete JVM actually implements this?

推荐答案

Java语言规范或Java虚拟机规范中没有规定任何特定实现策略的内容.每个实施者都可以自由选择他们想要的任何实施策略，只要结果与实施了规范中描述的算法的 AS-IF 相同.

There is nothing in the Java Language Specification or the Java Virtual Machine Specification that prescribes any particular implementation strategy. Every implementor is free to choose any implementation strategy they want, as long as the result is the same AS-IF they had implemented the algorithm described in the spec.

换句话说，规范中的算法描述的是最终结果，而不是食谱.

In other words, the algorithm in the spec describes the end result but not the recipe.

最简单，最明显的优化方法就是按照描述的那样愚蠢地执行算法，但是缓存而不是将其丢弃.

The simplest and most obvious possible optimization is to just stupidly perform the algorithm as described, but cache the result instead of throwing it away.

大多数现代高性能JVM均源自Smalltalk VM，并使用Smalltalk社区在1980年代发明的技术.

Most modern high-performance JVMs are derived from Smalltalk VMs and use techniques that were invented in the 1980s by the Smalltalk community.

Eclipse OpenJ9最初以IBM J9的身份出现，而IBM J9则源于IBM VisualAge for Java通用虚拟机(它能够无缝地执行JVM字节码和Smalltalk字节码的混合执行)，而它又是基于在IBM VisualAge for Smalltalk VM上.

Eclipse OpenJ9 started its life as IBM J9, which in turn is derived from the IBM VisualAge for Java Universal Virtual Machine (which was capable of seamlessly executing a mix of JVM byte code and Smalltalk byte code), which in turn was based on the IBM VisualAge for Smalltalk VM.

Oracle HotSpot基于LongView的Animorphic Smalltalk VM，而后者又基于Self VM. (变形Smalltalk VM也是Google V8 ECMAScript引擎的原始基础.)

Oracle HotSpot is based on the Animorphic Smalltalk VM by LongView, which in turn is based on the Self VM. (The Animorphic Smalltalk VM was also the original basis for Google's V8 ECMAScript engine.)

Azul Zing源自HotSpot. Oracle Labs Maxine RVM是由一些老的Smalltalk和Self开发人员根据Klein VM(用Self编写的实验性元循环Self VM)的思想开发的.

Azul Zing is derived from HotSpot. Oracle Labs Maxine RVM was developed by some old Smalltalk and Self developers based on ideas from the Klein VM (an experimental meta-circular Self VM written in Self).

一些消除动态运行时虚拟消息分发开销的最著名技术是

Some of the most well-known techniques for eliminating dynamic runtime virtual message dispatch overhead are

• 去虚拟化 –将动态运行时虚拟消息分发转换为静态方法查找:
  • JavaTM的虚拟化技术研究及时编译器 石崎和明(Kazuaki Ishizaki)，川本元弘(Motohiro Kawahito)，安藤俊明(Toshiaki Yasue)，小松英明(Hideaki Komatsu)，中谷俊雄(IBM Research)，东京(东京)
  • Devirtualization – turning dynamic runtime virtual message dispatch into static method lookup:
    • A Study of Devirtualization Techniques for a JavaTM Just-In-Time Compiler Kazuaki Ishizaki, Motohiro Kawahito, Toshiaki Yasue, Hideaki Komatsu, Toshio Nakatani (IBM Research, Tokyo)
    • 自定义:优化自身的编译器技术，一种动态类型的面向对象的编程语言，，克雷格·钱伯斯(Craig Chambers)和大卫·昂加(David Ungar)
    • Self的有效实现，Self是一种基于原型的动态类型的面向对象语言，，克雷格·钱伯斯(Craig Chambers)，大卫·昂加(David Ungar)和埃尔金·李(Elgin Lee)
    • Customization: Optimizing Compiler Technology for Self, a Dynamically-Typed Object-Oriented Programming Language, Craig Chambers and David Ungar
    • An Efficient Implementation of Self, a Dynamically-Typed Object-Oriented Language Based on Prototypes, Craig Chambers, David Ungar, and Elgin Lee
    • 使用运行时类型反馈优化动态调度的呼叫， UrsHölzle和David Ungar
    • Optimizing Dynamically-Dispatched Calls with Run-Time Type Feedback, Urs Hölzle and David Ungar
    • 迭代类型分析和扩展消息拆分:优化动态类型对象-定向程序，克雷格·钱伯斯和大卫·昂加
    • Iterative Type Analysis and Extended Message Splitting: Optimizing Dynamically-Typed Object-Oriented Programs, Craig Chambers and David Ungar
    • 单形内联缓存 ，
    • 双态内联缓存，
    • 多态内联缓存 :
      • 使用多态内联缓存优化动态类型的面向对象的编程语言， UrsHölzle，Craig Chambers和David Ungar
      • Monomorphic Inline Caching,
      • Duomorphic Inline Caching,
      • Polymorphic Inline Caching:
        • Optimizing Dynamically-Typed Object-Oriented Programming Languages with Polymorphic Inline Caches, Urs Hölzle, Craig Chambers, and David Ungar
        • Sista:投机内联，Smalltalk风格，Cadence Design的Eliot Miranda法国里尔INRIA的系统和ClémentBéra(来自Stanford Seminar的YouTube视频)
        • Sista: Speculative inlining, Smalltalk-style, Eliot Miranda of Cadence Design Systems and Clément Béra of INRIA, Lille, France (YouTube video from Stanford Seminar)
        • 自我的自适应优化:利用探索性编程调和高性能， UrsHölzle
        • 第三代自我实现:将响应能力与性能相协调， UrsHölzle和David Ungar
        • Adaptive optimization for Self: Reconciling High Performance with Exploratory Programming, Urs Hölzle
        • A Third-Generation Self Implementation: Reconciling Responsiveness with Performance, Urs Hölzle and David Ungar

        [您会注意到，几乎所有来源都来自于Self或Smalltalk.主要原因有两个，那就是Self率先采用了这些技术，而Smalltalk和Smalltalk VM对Java和JVM产生了重大影响.]

        [You will note that almost all of the sources are for either Self or Smalltalk. The two major reasons are that Self pioneered a lot of these techniques, and Smalltalk and the Smalltalk VM were a major influence on Java and the JVM.]

        我最熟悉的JVM(Eclipse OpenJ9，Oracle HotSpot，Oracle Labs Maxine RVM，Azul Zing)实现了以上大部分功能.

        The JVMs I am most familiar with (Eclipse OpenJ9, Oracle HotSpot, Oracle Labs Maxine RVM, Azul Zing) implement most of the above.

        Java 7的JVM规范中引入的invokedynamic字节码允许程序员访问上述优化，但是提供他们自己的方法查找算法，而不是将其硬编码到JVM中.这样就可以在JVM之上为方法查找算法与Java的语言不兼容的语言创建高性能的实现.

        The invokedynamic bytecode introduced into the JVM Specification in Java 7 allows programmers access to the above optimizations but supply their own method lookup algorithm instead of the one hard-coded into the JVM. This makes it possible to create high-performance implementations on top of the JVM for languages whose method lookup algorithm is incompatible with Java's.

        这篇关于在JVM中实现invokevirtual的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！