How is the code generated by the JIT compiler related to the program?

I am trying to understand how the JIT compiler works. I already got the basic idea of ​​generating dynamic code at runtime, but I don't understand how the generated code is associated with the program? Through a dynamic library? It would be nice if someone could share a "hello world" JIT compiler example to explore.

+3


source to share


1 answer


The simple answer is that JITter keeps a symbol table around the entry points of other functions (compiled or not) complete with signatures, and stores the descriptions of abstract objects around containing member variables and assigned offsets into the object's real memory implementation.

Then, when JIT compiling a function call, it can look for the function (in a classic way that a pure Java compiler can use) and generate the call. (If this were my JIT system, I would build a dummy stub in machine code for each uncompiled method that was called JITter when it got control. Then each compiled function always calls machine code for the callee. Entry in the DLL, you use a stub to hide the real thing.)

When a new class definition is found, it creates a symbol table entry for that class, finds the member variables, and assigns offsets. (This is a little complicated by the fact that one class can inherit from another: in a system with one inheritance like Jav, all you really need to do is write the assigned offsets for the new member variables, taking into account the already assigned indents from the parent classes) ...



When JIT compiling a reference to a member variable, it looks for the type of the object, finds the member information, grabs the offset, and uses it.

You can find variations on this scheme, but in general it should be something like this. This is pretty much what a pure compiler should have done; you just delay the work until an object or method is found at runtime.

+1


source







All Articles