[Vm-dev] Class checks in the vm

[Eliot Miranda]

On Wed, Apr 18, 2012 at 3:34 AM, Guillermo Polito <guillermopolito at gmail.com
> wrote:

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

Read the class comment of CogMemoryManager in a Cog VMMaker,
e.g. VMMaker-oscog-EstebanLorenzano.156 or VMMaker.oscog-eem.157

HTH


>
> Thank you!!
> Guille
>
>
>>
>>
>>> Thanks!
>>> Guille
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120418/04dbb07e/attachment.htm