JIT编译代码驻留在哪里？ [英] Where does the JIT compiled code reside?

问题描述

所以我有这个用Java编写的方法：

So I have this method, written in Java:

public void myMethod(int y){
    int x = 5 + y;
    doSomething(x);
}

并假设我的应用程序多次调用它..

And assume my application calls this a lot of times..

在Java虚拟机上运行此方法的已编译代码时，JVM将首先解释该方法。如果我理解正确，一段时间后它会决定将其编译成机器语言。

When running the compiled code for this method on Java Virtual Machine, JVM will first interpret the method. Then after some time it will decide to compile it to machine language if I understand correctly.

此时，

它会被内存中的机器代码覆盖吗？如果它被覆盖，那么尺寸差异的问题将如何解决？如果它被写入内存中的其他位置，那么加载到内存中的字节码是否会被释放？而且，如果字节码和jit编译的代码都在内存中，当应用程序再次遇到此方法时，JVM如何决定执行jit编译代码而不是字节代码？

Will it be overwritten by the machine code in the memory? If it is overwritten, how will the issue of the size difference solved? If it is written to some other place in memory, will the bytecode loaded into memory freed or not? And also, if both bytecode and the jit compiled code is in the memory, when the application hits this method again, how does JVM decide to execute the jit compiled code instead of byte code?

推荐答案

HotSpot JVM有方法结构（或早期版本中的PermGen）。
它包含永远不会被覆盖的方法字节码，并且一个指向已编译代码的指针，在编译该方法之前一直为NULL。

HotSpot JVM has a Method structure in Metaspace (or PermGen in earlier versions). It contains method bytecode which is never overwritten and a pointer to compiled code, initially NULL until the method is compiled.

一个方法可能有多个入口点：

A method may have multiple entry points:

• _i2i_entry - 指向字节码解释器的指针。


• _code-> entry_point（） - JIT编译代码的入口点。编译后的方法驻留在 CodeCache - VM动态生成代码的本机内存的特殊区域。


• i2c 和 c2i 从解释器调用编译代码的适配器，反之亦然。这些适配器是必需的，因为解释的方法和编译的方法具有不同的调用约定（如何传递参数的方式，如何构造帧等）。

• _i2i_entry - a pointer to the bytecode interpreter.
• _code->entry_point() - an entry point to the JIT-compiled code. Compiled methods reside in CodeCache - the special region of native memory for the VM dynamically generated code.
• i2c and c2i adapters to call the compiled code from interpreter and vice versa. These adapters are needed, because the interpreted methods and compiled methods have different calling convention (the way how arguments are passed, how frames are constructed etc.)

在某些极少数情况下，编译后的方法可能会有不常见的陷阱，这些陷阱可以回溯到解释器。此外，Java方法可以多次动态重新编译，因此JVM不能丢弃原始字节码。无论如何都没有意义释放它，因为字节码通常比编译的代码小得多。

A compiled method can have uncommon traps that fall back to interpreter in some rare cases. Furthermore, a Java method can be dynamically recompiled multiple times, so JVM cannot throw away the original bytecode. There is no sense to free it anyway, because the bytecode is usually much smaller than the compiled code.

这篇关于JIT编译代码驻留在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！