[Vm-dev] Re: Multiple Bytecode Sets

[Eliot Miranda]

Hi Stefan,

On Tue, Oct 16, 2012 at 12:11 PM, Stefan Marr <Stefan.Marr at vub.ac.be> wrote:

> Hi Eliot:
>
> May I ask you to give me a brief, high-level description of how the
> support for multiple bytecode sets works?
>

sure.


> Do you switch between different dispatch tables based on the method flag?
> Or do you extend the existing one and include the bit into the dispatch?
>

This scheme is suggested by Claus Gittinger, and he uses something very
similar in Smalltalk/X.  The idea is merely to include an offset that
selects the bytecode set in the dispatch and set this offset on every send
and return.  So with two bytecode sets there are 512 cases in the
interpreter's dispatch loop and the offset is either 0 or 256.  In the
Squeak VM this means code such as

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

setMethod: aMethodObj
"Set the method and determine the bytecode set based on the method header's
sign."
<inline: true>
method := aMethodObj.
self assert: (objectMemory isOopCompiledMethod: method).
bytecodeSetSelector := (self methodUsesAlternateBytecodeSet: method)
ifTrue: [256]
ifFalse: [0]

methodUsesAlternateBytecodeSet: aMethodObj
<api>
<inline: true>
"A negative header selects the alternate bytecode set."
^self headerIndicatesAlternateBytecodeSet: (self headerOf: aMethodObj)

headerIndicatesAlternateBytecodeSet: methodHeader
"A negative header selects the alternate bytecode set."
^(objectMemory integerValueOf: methodHeader) < 0

Do you have any performance numbers, or pointers to literature?
>

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

fetchNextBytecode
"This method fetches the next instruction (bytecode). Each bytecode method
is responsible for fetching the next bytecode, preferably as early as
possible to allow the memory system time to process the request before the
next dispatch."

self cppIf: MULTIPLEBYTECODESETS
ifTrue: [currentBytecode := self fetchByte + bytecodeSetSelector]
ifFalse: [currentBytecode := self fetchByte]

That was easier than trying to define bytecodeSetSelector as 0, e.g. via a
macro.

I found hints to Smalltalk/X, VisualAgeJava/Smalltalk, and I think
> MagLev/Gemstone might also use that kind of technique.
> But, unfortunately, Google is a bit shy about papers, or interesting
> references.
>

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.

Thanks a lot
> Stefan
>

-- 
cheers,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20121016/1a21bbd9/attachment.htm