[Vm-dev] Re: Multiple Bytecode Sets

[Stefan Marr]

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.

Thanks
Stefan

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525