On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote: > At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote: > >At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote: > >>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote: > >>> The Java VM does this by popping values off of the local stack, and > >>> onto the callee's stack upon return. > >> > >>I think this is a design mistake of the Java VM. It would have been > >>more efficient to keep the local variables on the stack.
Java separates each stack frame into a local variable array and a local stack (containing the intermediate values). During a method invocation, the method arguments are copied from the caller local stack to the callee local variable array. It would have been clearly more efficient, but slighly harder, to implement to access the argument directly from the caller frame. The Java bytecode interpreter is clearly not optimized for speed. David Gregg, Anton Ertl and Andreas Krall have experimented with an improved Java bytecode interpreter. One of the optimisations they perform is to get rid of this copying. Overall, they get a factor 5 to 10 improvement on some JavaSPEC benchmarks over other Java bytecode interpreters. (See "A fast Java interpreter" and "Implementing an efficient Java interpreter" from http://www.complang.tuwien.ac.at/papers/ By the way, Anton Ertl has written a lot of other very good papers on bytecode interpreters.) > >Yeah, that's too much work for me. I'd rather do something simpler, even > >if that boils down to "we return a single ParrotList with all the return > >values in it, stuck in P0". Yes, that would be fine. We can still optimize this later if necessary. The paper "An Efficient Implementation of Multiple Return Values in Scheme" by Ashley and Dybvig present a possible implementation. (http://citeseer.nj.nec.com/ashley94efficient.html) -- Jerome
