More fun with VMs [was: Re: Bug: Use of == ...]

Dan Ingalls Dan at SqueakLand.org
Wed Feb 15 19:29:49 UTC 2006


Hi, Stef -

[I'm copying this to Sq-dev because I figured a number of other folks might be interested in this]

>Should I understand that the underlying structure are not C but Java. So this is a bit like in Hobbes.?
>Does it means that you do not have to deal with GC?

Yes, yes, and yes.

>You get all the dynamism of Smalltalk because you do not use directly the Java byte-code.
>When you redefine a method you just install the method bytecode in the class ST objects
>and the interpreter will interpret the Smalltalk byte-code

Other than the use of Java objects for the objects, it's really an emulation -- ie, it does not use Java classes for ST classes.  To summarize, I have only a few classes...

	SqueakObject -- all Sq objects are an instance of this class.
		sqClass - points to another SqueakObject, the class
		format - like Squeak
		hash - like Squeak
		pointers - all pointer fields, named and indexable, if there are any
		bits - all bit-like fields, if there are any
	Clearly this can later be optimized with variants for a number of common
	Squeak formats (Hobbes does this as well).  I'm trying to keep this very
	simple for now, though.

	Integer - I use Java's Integers (boxed raw ints) for SmallIntegers.  This allows
		the pointer space to be uniformly Java Objects.  This is what revealed
		the ==/= problem.  The easy fix is integer checks in ==, but I planned
		all along to do interning of small values to improve performance of
		all SmallInteger traffic.

	SqueakImage - mostly devoted to reading the image, but it also includes a
		weak object table used for enumeration.

	SqueakVM - the central interpreter

	SqueakPrimitivehandler - all the primitives

>I guess that you do not generate Java native byte code?
>Gilad was mentioning that they will introduce a new bytecode for dynamic lookup in Java.

Correct;  I do not generate Java bytecode (remember this is *simple*).  But of course that is a possible approach for adding a JIT.  Of more likely value in the short term is to modify the CTranslator to produce Java, and thus effectively offer AOT (ahead-of-time) compilation of primitives and any other performance-critical code.

	- Dan



More information about the Squeak-dev mailing list