[Vm-dev] Class checks in the vm

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 17 16:13:12 UTC 2012

Hi Guillermo,

On Tue, Apr 17, 2012 at 8:33 AM, Guillermo Polito <guillermopolito at gmail.com
> wrote:

> Hi!
> I'm playing to bootstrap a Pharo image, trying to get a new environment
> running into my 'host' image, and after that, dump those new objects into a
> new image file.
> Now, to do that, I'm creating new classes for String, Character...  Which
> are well known by the vm specialObjectsArray.  And trying to initialize my
> new image classes, which creates new character objects, and new string
> objects which is causing me some troubles :P.
> Now, my question is about this check in vmmaker (and some others that look
> similar):
> Interpreter>>#asciiOfCharacter: characterObj  "Returns an integer object"
>     <inline: false>
>     *self assertClassOf: characterObj is: (self splObj: ClassCharacter).*
>     successFlag
>         ifTrue: [^ self fetchPointer: CharacterValueIndex ofObject:
> characterObj]
>         ifFalse: [^ ConstZero]  "in case some code needs an int"
> - Can't we put a more intelligent assersion like checking if the object
> responds true to #isCharacter?

The issue is performance.  One wants as quick a test here as possible, so
testing the class of the receiver is faster than doing a probe on the
method lookup cache and much faster than possibly having to do a full class
lookup.  So realistically the answer is "no, we shouldn't".

> - And removing the static check from the vm and adding the dynamic and
> nice #isCharacter check into the image?

 This doesn't make a lot of sense.  asciiOfCharacter: is being used in the
VM by various primitives (e.g. at:put: on strings) and its use is to fail
if one attempts to store other than a character in a string.  So moving the
test to the image means the primitive is not safe.  Keep on moving in this
direction and you end up with a system that will crash when one makes an
error instead of raising an error message.  Smalltalk is a safe language;
it is extremely important that the system not crash and instead provide
walkbacks that afford diagnosis of errors.

The real issue here is that you want more flexibility in the VM while
bootstrapping than one wants or needs in normal use.  Instead of making the
VM slow and more general than it need be the right approach is to create a
variant of the VM for your bootstrapping use.  You can do this by creating
a subclass of Interpreter which reimplements asciiOfCharacter: (and others
you may need) and testing it in the simulator.  You can then use your
flexible VM for the bootstrap and once complete use the normal VM.

> Thanks!
> Guille

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120417/023153f3/attachment.htm

More information about the Vm-dev mailing list