On Tue, Oct 16, 2012 at 12:11 PM, Stefan Marr
<Stefan.Marr@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
<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