[virtmach] VM with garbage collection
Chris Dollin
virtmach@iecc.com
Fri, 11 Jan 2002 15:31:32 +0000
Joachim wrote:
> > From: Chris Dollin [mailto:kers@hplb.hpl.hp.com]
> >
> > * given the overheads of an interpreted VM, one extra
> > indirection in the relevant instructions isn't much overhead
>
> This cuts the other side as well: since VMs are so slow, any speedup that
> can be taken should be taken. This makes the difference between overhead
> factors of 10 and 1000.
If I expected to write the interpreter in assembler, I would be more
likely to agree. But even so, the sums are non-trivial. Consider:
The "load constant" instruction can either be implemented as
REGS[REGISTER[instr]] := EXTERNALS[XINDEX[instr]]
with the indirection, or as
REGS[REGISTER[instr]] := GETTHEXTERNAL[pc,instr]
with various bindings for the REGS etc. Now, if GETTHEEXTERNAL has
to reach further into the instruction stream (eg *pc++, and let's hope the
thing is aligned), that's anyways another indirection. The GC now has to
pay the price of scanning the instruction stream to relocate the reference;
this may or may not cost as much. (If the reference has to be extracted
byte-by-byte, I'm put money on it being a loser.) If the instruction has
got all the bits in it, you're paying more for the store requirements of the
instruction stream, so you're more likely to blow the instruction cache.
So it's really not clear if avoiding the indirection is a speedup on
anything other than the micro scale. Does anyone have references
to real analysis in this area?
> Besides, VM optimizations are the most rewarding, since they will speed up
> the entire software. Any optimization further up in the software layers will
> have a lower payoff.
That depends. Upper analysis might eliminate some code completely.
Or it may be able to determine that a faster unsafe instruction will do the
job (ie the VM should have both safe and unsafe instructions, if
you can trust the code its running).
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html