How method-based JIT compiler handles class field members

Question

The Just-In-Time (JIT) compiler references a compiler that translates a code into native code at program runtime. Normally, it translates the Bytecode to machine code for Java programming language.

There are general two kinds of JIT compilers: method-based jit and trace-based jit. The former mostly profiles runtime program, and only choose the hot method for compilation.

My question here is how JIT compiler handle class field members? _b refers a new created Java object on the Heap. So how does JIT compiler translate getField instruction when the method 'test(string)V' is selected for jit compilation? Is there any jump back and forth between generated native code and bytecode here?

class A{
   MyObject _b = new MyObject(..);

   public void test(String ars){
       aload 0 
       getField A::_b MyObject
       invokvirtual MyObject sayHello (String)V
       ...
   }
}

The operand stack is purely an abstraction used to define the semantics of bytecode. There's no reason for the JIT to actually simulate a stack, and in fact the bytecode is carefully designed so that this is not necessary. — Antimony, Jul 25 '15 at 02:22

score 0 · Answer 1 · answered Jul 25 '15 at 07:07

0

The HotSpot virtual machine maintains a stack of method frames. This stack does normally contain both compiled and interpreted frames, depending on the "hotness" of the executed code.

An object allocation can be performed in any way from the JIT-compiled code, as long as the semantics of the byte code program do not change. If the compiler can prove that the object is never used, it can even avoid the allocation alltogether as this would not change the mentioned semantics.

answered Jul 25 '15 at 07:07

Rafael Winterhalter

42,759
13
108
192

Do you mean both generated native instructions and bytecode instructions are on JVM stack at runtime? – shijie xu Aug 02 '15 at 00:56
For different methods, yes. – Rafael Winterhalter Aug 02 '15 at 07:37

score 0 · Accepted Answer · edited May 23 '17 at 12:14

You question “how JIT compiler handle class field members”, contains two wrong assumptions. First, there is not “the” JIT compiler that we can talk about, there are plenty of different existing JIT compilers/ optimizers and even if we restrict ourselves to the behavior of Oracle’s JVM, we can’t make a blanket statement. Second, there is no handling of a single feature, especially as simple as a field access, in isolation.

It’s not clear why you think there was an interaction between compiled and interpreted code during the execution of a getfield instruction. Regardless of how a JVM implements object references, they are a kind of value and reading the value of field _b just means reading a value from memory. The writing of a value to the field, i.e. the reference to a newly created object, happens inside A’s constructor, not when the field is read. And the state of the code is completely irrelevant for that memory access.

When it comes to the invokvirtual instruction, it’s execution may imply a change from interpreted mode to compiled code or vice versa. But, again, this has nothing to do with the preceding getfield instruction. It wouldn’t be different, if the target object reference is the result of an aload instruction or a preceding method invocation or a new allocation right inside the method. It only depends on the state of the code of the invoked method, that is MyObject.sayHello or an overriding method of a subclass.

As Antimony has pointed out, when the method is being compiled/optimized, the resulting code is unlikely to model a stack on mainstream CPUs. The resulting native code won’t push a reference to the stack but just read the field value straight-forwardly and use it for the subsequent invocation. The reference might get temporarily stored into a CPU register but it is also possible that the read operation and the invocation get fused into a single instruction if the target CPU can handle such indirect addressing. It’s also possible that the code of sayHello gets inlined and the optimizer’s overall result has no reminiscence of the original code at all.

The original puzzle about interaction is how Java objects on the heap are manipulated by compiled code. It is much clearly. Do you have any links for transition between compiled code and byte-code when seeing an ``invokevirtual''? — shijie xu, Aug 02 '15 at 01:39

How method-based JIT compiler handles class field members

2 Answers2