harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Lougher <rob.loug...@gmail.com>
Subject Re: Other interesting papers and research
Date Mon, 06 Jun 2005 13:58:45 GMT
Hi,

On 6/6/05, shudo@computer.org <shudo@computer.org> wrote:
> Hi Dave,
> 
> > From: David P Grove <groved@us.ibm.com>
> >
> > One thing to
> > note is that a threaded interpreter would see something like a 2-4x
> > expansion over "normal" bytecodes when it converts from bytecodes to its
> > internal form (arrays of function pointers).
> 
> Direct threading interpreters like JDK's one work on plain Java
> bytecode and they do not need to expand normal bytecode instructions.
> Such expansion may have been required if Java bytecode is not linear
> and rather a tree or other complicated form.
> 

According to my understanding, an indirect threaded interpreter uses
the original bytecode stream.  It's indirect because the handler
address must be looked up via the bytecode.  A direct threaded
interpreter removes this step by placing the actual handler addresses
in the rewritten instruction stream.

For what it's worth, JamVM supports both direct and indirect
threading, with static and dynamic stack-caching respectively.  I seem
to recall an average code size increase of ~4x for JamVM's internal
instruction format but I'll need to recheck my figures to be sure. 
Note, this is assuming a 32-bit architecture.  Handler addresses will
be double on a 64-bit machine, and the code increase over bytecodes
therefore larger.

Rob.

Mime
View raw message