[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Levente Uzonyi]

On Sat, 16 Jun 2012, Igor Stasenko wrote:

>
> On 16 June 2012 03:42, Levente Uzonyi <leves at elte.hu> wrote:
>>
>> On Thu, 14 Jun 2012, Igor Stasenko wrote:
>>
>>>
>>>> To be honest, I'm a little puzzled by the resistance to immutability.
>>>
>>>
>>> and also, because i am strong proponent of reducing a number of
>>> contracts between VM and language.
>>> Things, like moving scheduling logic to image side, moving identity
>>> hash logic to image side etc etc.
>>> which makes VM less complex, by having less contracts.
>>> This is a part of my holy crusade against complexity :)
>>
>>
>> IIUC you want to push stuff from VM side to the image. And you want to add a
>> properties slot for all objects in the new VM. Why don't you do that in the
>> image? It's the same as adding an instance variable to Object/ProtoObject,
>> isn't it? :)
>>
> In theory yes, but in practice, existing object format(s) do not allow
> you to do that:
> try adding instance variable to any variable class with bytes/words format.

Right, Colin also mentioned another contract that would make it impossible 
with the current VM, but we're talking about a new VM, aren't we?

>
> So, one way or another you will need to change the object format to allow that.
> And if VM would allow you to do things like you describing, then it
> will be even better - no extra responsibility from VM, just add an
> instance var.
> But your smiley at the end means irony, like i proposing something
> very silly, right?

Not at all, it's about the simplicity of this idea.

Btw, I'm not sure if it's worth adding an extra slot to every object. 
Maybe it's worth using a bit in the object header to mark objects which 
have the properies slot and keep the slot management at the VM side. When 
the slot is about to be accessed check the bit and use lazy become if 
there's none yet. Of course someone should do the hard work and make some 
measurements before deciding about this n+1th idea.

>
> So allow me also be ironic/moronic a bit..
>
> Just take a look at nice and beautiful implementation of dependents
> protocol of Object.
> So, every Object in system can have additional property , named "dependents".
> Sounds close to what i proposing.. But of course it would be silly to
> implement it differently
> comparing to current implementation. For sure, you should use huge,
> weak identity dictionary,
> where you store this property.
>
> But lets move on to Morphs.. ahhh yeah.. morphs came to us from Self
> where any object
> could have as many properties as it wants. But since we cannot afford
> that, what we do?
> Yeah, we build a piles of mess, then call it MorphExtension and
> everyone happy, and keep *rolling eyes* at silly idiots like me.
>
> And the last thing.. you could ask: where is Compiled methods store
> their properties, like pragmas etc?
> I will answer: At very obvious and right place where you can find it,
> it is just needs some elaboration:
> - second to last literal in it's literals array, unless it is reserved
> by method's selector,
> then it is held by "AdditionalMethodState", very similar to what both Object and
> MorphExtension doing.
> Do doubt, if you do it any other way, you will be just an idiot!
>
> And sure thing, all of these examples showing very beautiful and
> elegant way how we should organize an object's data structure, when
> you cannot predict in advance, how many properties it may need.

These could be simplified/eliminated with your proposal and you could 
also use the properties slot to add immutability as you suggested, but I 
still don't see how these (and other external tools' and frameworks') 
different uses of the properties slot won't conflict with each other.


Levente

>
>
> -- 
> Best regards,
> Igor Stasenko.
>