Where does the JIT compiled code reside?

Question

So I have this method, written in Java:

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

And assume my application cal

Answer 1

No, it's not overwritten, because there is usually no practical benefit in the two representations being at the same place. The JVM bytecode is just a piece of data. The JIT-emitted code is a stream of native CPU instructions (in some architectures, it is required that this is explicitly marked as executable).

Typically, when a new function is required for execution, the JIT compiler reads the bytecode of that function, allocates memory somewhere else, writes the equivalent native code to that memory, then returns a function pointer to the entry of the newly generated native code.

Answer 2

As far as I know, the The Java® Virtual Machine Specification does not specify any of that.
The only reference to JIT I can find is in Chapter 3:

[...] One example of such a translator is a just-in-time (JIT) code generator, which generates platform-specific instructions only after Java Virtual Machine code has been loaded. This chapter does not address issues associated with code generation, only those associated with compiling source code written in the Java programming language to Java Virtual Machine instructions.

So to my understanding, this can be done differently by different implementations.

However, to me it seems very unlikely that the memory containing the java bytecode is overwritten with native CPU instructions, because CPU instructions are technically executable and bytecode is just data, as it has to be interpreted. It wouldn't be impossible though, just very odd.

Answer 3

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 - 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.)

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.