Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Re: [Vm-dev] stack vm questions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Eliot Miranda-2

[squeak-dev] Re: [Vm-dev] stack vm questions

Hi Jecel,

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 also.

On Thu, May 14, 2009 at 4:36 AM, Jecel Assumpcao Jr <[hidden email]> wrote:

[snip]

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
example.

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 restrictions.

- 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.

Best

Eliot