Hi, On 6/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > From: David P Grove <[EMAIL PROTECTED]> > > > > 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.
