|JIT machine code generation SRINIVASANP@phibred.com (Srinivasan, Pattabi) (1997-07-29)|
|Re: JIT machine code generation email@example.com (1997-07-31)|
|Re: JIT machine code generation Sergey.Solyanik@bentley.com (Sergey Solyanik) (1997-08-07)|
|Re: JIT machine code generation firstname.lastname@example.org (1997-08-12)|
|From:||Sergey Solyanik <Sergey.Solyanik@bentley.com>|
|Date:||7 Aug 1997 15:25:07 -0400|
|Organization:||Bentley Systems, inc|
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
> The classic reading on this
Here's my small collection of references:
Best regards --
Sergey Solyanik (mailto:email@example.com)
Return to the
Search the comp.compilers archives again.