Re: JIT machine code generation

Sergey Solyanik <>
7 Aug 1997 15:25:07 -0400

          From comp.compilers

Related articles
JIT machine code generation (Srinivasan, Pattabi) (1997-07-29)
Re: JIT machine code generation (1997-07-31)
Re: JIT machine code generation (Sergey Solyanik) (1997-08-07)
Re: JIT machine code generation (1997-08-12)
| List of all articles for this month |

From: Sergey Solyanik <>
Newsgroups: comp.compilers
Date: 7 Aug 1997 15:25:07 -0400
Organization: Bentley Systems, inc
References: 97-07-119 97-07-131
Keywords: interpreter

David Keppel wrote:
> For systems that compile a function at a time, the transfer is often
> of the form "(*ptr)(...)" and the callee may have other calls embedded
> in it directly, with stub calls for routines that weren't compiled at
> the time the callee was compiled.

Obvious place for transfer to transfer control to JIT code is method
invocation function. Once there, you can decide using information from
method header, if this method has already been compiled, compile it if
it hasn't been done, and call via function pointer. Or you can invoke
backup interpreter if compilation had failed. This approach is most
usable for systems that deal with JIT on per-method basis. Pro is
simplicity of implementation and compilation speed (you only compile
what you use). Contra is slight (or not so slight) inefficiency --
quite a bit of time is wasted in the stub function.

> For systems that do more fine-grained compilation, a direct jump is
> more commonly used with some assembly hair to make sure the system
> is sane when control passes out of the dynamically-compiled code.

I haven't heard of this (outside of adaptive inlining, which does not,
strictly speaking, "jump"). Do you know of any system that actually
implement this?

> The classic reading on this

Here's my small collection of references:

Best regards --

Sergey Solyanik (

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.