Found a paper from David too... http://www.research.ibm.com/people/d/dgrove/papers/cgo05.html
On 6/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Rob, > > > From: Robert Lougher <[EMAIL PROTECTED]> > > Date: Mon, 6 Jun 2005 14:58:45 +0100 > > > > > 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. > > Ah, thanks for the indication. > My wording 'direct threading' was not correct. > > Threading (interpreting) techniques I referred as implemented in JDKs > should be called 'token threading', neither direct nor indirect threading > because they work directly on bytecode instructions withought any expansion. > Note that the interpreter provides NEXT routines to for all native > code fragments corresponding to VM instructions. > For JVM, this wording like something threading is not very informative > because direct interpretation of portable bytecode is naturally > 'token threading'. > > Dave's last posting was based on direct threading technique and his saying > was correct about direct threading but my posting was incorrect in advance. > > Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/ > -- Davanum Srinivas - http://webservices.apache.org/~dims/
