[Vm-dev] Re: Multiple Bytecode Sets

Stefan Marr smalltalk at stefan-marr.de
Tue Oct 16 20:46:13 UTC 2012

Hi Eliot:

On 16 Oct 2012, at 22:32, Eliot Miranda wrote:

> StackInterpreter methods
> fetchNextBytecode
> 	"This method fetches the next instruction (bytecode)."
> 	currentBytecode := self fetchByte + bytecodeSetSelector

Thanks, that's what I was looking for.

> I couldn't see much of an impact when I measured it, but I don't have my measurements handy.  Modern processors cache the read so well that even in the interpreter impact is minimal (it was certainly less than 10%, probably less than 5%, in a pure interpreter), and of course in the JIT it matters not at all.  But the impact was enough that I ended up conditionalizing the code so it reads

Hm, ok. Sounds better than the 5-30% hit I have for having a check inside the bytecodes to have different semantics.

> I don't suppose its something people do a lot.  Claus' VM is the only one I was aware of.  I think its useful to support multiple languages and to support migrating the bytecode set using incremental development, but in a production VM if one didn't need the support I think one would end up disabling it.

The other example I found is the LuaJIT2 interpreter.
It is used to enable and disable debugging hooks, as far as I understand.
But since it is written in assembler, it is just patching the dispatch table
and let's the bytecode jump to different code when the debugging hooks are enabled.
But I didn't see any performance numbers for that. Would guess it would take some interaction with the OS to deactivate protection on executable memory pages to change the dispatch table.


Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

More information about the Vm-dev mailing list