[Vm-dev] Class checks in the vm

[Guillermo Polito]

On Tue, Apr 17, 2012 at 6:13 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

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

I was not totally aware of the performance issues (I knew there were going
to be some tradeoffs, but not so critical :) ).  Now, for the bootstrap,
I'll talk with my mentors to see which should be a nice approach to reach
where we want to be.

BTW, you were talking about better object representation and inmediate
characters, can you give me a pointer of what you mean? (just curious)

Thank you!!
Guille


>
>
>> Thanks!
>> Guille
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120418/d3f872a3/attachment.htm