[Vm-dev] stack vm questions
eliot.miranda at gmail.com
Thu May 14 16:00:23 UTC 2009
you ask some pointed questions on the Stack & JIT Cog VMs that need good
answers and I suspect are generally interesting so I'll answer to squeak-dev
On Thu, May 14, 2009 at 4:36 AM, Jecel Assumpcao Jr <jecel at merlintec.com>wrote:
> Eliot wrote:
> > Yes. In the JIT an interpreted frame needs an extra field to hold
> > the saved bytecode instruction pointer when an interpreted frame
> > calls a machine code frame because the return address is the "return
> > to interpreter trampoline" pc. There is no flag word in a machine
> > code frame. So machine code frames save one word w.r.t. the
> > stack vm and interpreted frames gain a word. But most frames
> > are machine code ones so most of the time one is saving space.
> Ok, so the JIT VM will still have an interpreter. Self originally didn't
> have one but most of the effort that David Ungar put into the project
> when it was restarted was making it more interpreter friendly. The
> bytecodes became very similar to the ones in Little Smalltalk, for
> Will images be compatible between the JIT VM and the Stack VM?
At least in the first version of the JIT yes. There are a couple of
- the code that rebuilds the Character table in
SystemDictionary>>recreateSpecialObjectsArray has to be replaced by code
that simply copies the table. This is because the JIT caches the Character
table's oop in the generated machine-code for the at: primitive
- the use (e.g. in Pharo) of the SmallInteger primitives 1 through 17 on
LargePositiveInteger must be replaced by the relevant large integer
primitives, which will be included in both the Stack and JIT Cog VMs.
But I do expect to evolve the object representation quite soon, and this
will break image backward-compatibility altogether. But I will want to
produce a Stack VM that is compatible with the new format, not just a JIT VM
because platform spread is very important to maintain and it'll be a while
before more ISAs than x86 will be supported.
Or do you
> expect the latter to not be used anymore once the JIT is available?
I expect that an interpreted Stack VM will survive for a long time and be
the standard VM on ISAs such as SPARC, Itanium, MIPS, while the JIT will be
available probably in the following order IA32/x86, ARM32, x86-64, PowerPC.
I had originally understood that the Stack VM would be compatible with
> older images (since you divorce all frames on save and remarry them on
> reload) but I had missed the detail of the different bytecodes for
> variable instance access in the case of Context objects.
No, the Stack VM is not compatible with older images. The Context VM with
closure bytecode extensions (e.g. John's current 4.0 beta VM) is
backward-compatible and is the bridge over which one can bring forward
pre-closure images to the Stack VM and JIT VM which are Closure-only VMs.
One could make the Stack VM run older images but it would be difficult (and
hence probably buggy) and I think unnecessary. One can always run older
images on older VMs for as long as OSs support the older executables (and
that other VM technology makes that easier these days). One can migrate an
older image forward to the Stack VM using the bootstrap and the Context VM
with Closure extensions. Packaging technologies such as Monticello make
images much less important these days. One should expect to be able to
export one's code in the form of a package and load it into a newer image,
perhaps with a little massage. So keeping those dusty decks running on
up-to-date VMs is IMO both wasted effort and a hindrance to obtaining
maximum performance on newer VMs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev