JIT-compiling bytecode

Lauri Alanko <la@iki.fi>
4 Nov 2005 14:04:05 -0500

          From comp.compilers

Related articles
Register Based Interpreter Model acampbellb@hotmail.com (Avatar) (2005-11-01)
Re: Register Based Interpreter Model christian.mueller@aktivanet.de (2005-11-02)
JIT-compiling bytecode la@iki.fi (Lauri Alanko) (2005-11-04)
Re: JIT-compiling bytecode eliotm@pacbell.net (Eliot Miranda) (2005-11-08)
| List of all articles for this month |

From: Lauri Alanko <la@iki.fi>
Newsgroups: comp.compilers
Date: 4 Nov 2005 14:04:05 -0500
Organization: University of Helsinki
References: 05-11-016 05-11-025
Keywords: code
Posted-Date: 04 Nov 2005 14:04:05 EST
Originator: lealanko@cc.helsinki.fi (Lauri Alanko)

In article 05-11-025, <christian.mueller@aktivanet.de> wrote:
> Some authors argue that a register machine is more complicated but a
> better starting point for jitting.

The idea of jitting _bytecode_ seems rather strange to me in the first
place. Bytecode is a _target_ language, after all, designed to be
efficiently interpreted by a VM with only straightforward
modifications (threading, symbol resolution), but no real syntactic
analysis. It is not a particularly good intermediate language from
which to translate to native machine code. For example, bytecode fixes
the evaluation order completely, so a jit-compiler needs to go through
hoops to reorder the computations optimally for the target platform.

To my mind, if a VM is supposed to support jitting, the code should be
stored in some higher-level format, which is then jitted at run-time
to a target language (native code or interpreted bytecode).


[Bytecode can be though of as a linearized version of a parse tree. I
don't see that it makes the situation any worse unless you want the
compiler to do a bunch of dependency analysis and dump out the
analysis results along with the code. -John]

Post a followup to this message

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