[Vm-dev] Class checks in the vm

[Nicolas Cellier]

Le 18 avril 2012 12:34, Guillermo Polito <guillermopolito at gmail.com> a écrit :
>
>
>
> 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)
>

Character would be encoded directly in the object pointer like
SmallInteger already are.

Nicolas

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