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
|