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

Levente Uzonyi leves at elte.hu
Sun Jun 17 05:09:22 UTC 2012


On Sat, 16 Jun 2012, Igor Stasenko wrote:

>
> On 16 June 2012 18:01, Levente Uzonyi <leves at elte.hu> wrote:
>>
>> 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?
>>
> yes.
> Then i agree. We could have a contract that all objects will have at
> least 1 instance var (or call it reference),
> and VM don't needs any knowledge and should not put any additional semantics
> related to that ivar, except from providing a way to access it.
> Then, as before, VM is free to add extra semantic value to next slots,
> like in case of Behavior
> and indexes of supeclass , method dictionary and format ivars.
> So, in practice it will mean that we will have to increase offsets of
> all currently 'contracted' ivars
> in VM (and plugins) by 1.
>
>
>
>>>
>>> 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.
>>
>
> Well, we can have it either mandatory or optional (if bit set). It is
> implementation detail
> and we actually should test which one is more efficient in terms of
> speed/space tradeoff :)
>
> But if it mandatory, then it combines quite well with lazy become.
> The lazy become requires at least one extra word per object to store
> forwarding pointer there,
> because you cannot replace an object's header with forwarding pointer,
> because header
> holds an information how much memory is reserved for given object, and
> if you wipe that information,
> you will have big problems walking the memory heap and condensing unused space.

If objects are aligned to 4 (or 8) bytes then there are 2 (or 3) free bits 
per pointer. If you use two of these bits to store 3 states: valid object, 
forwarded object with no slots, forwared object with slots (object size is 
stored in next slot) and the object header also uses these 2 bits the 
same way, then you don't need the extra word and you can find out the size 
of the forwarded objects.

>
>>>
>>> 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.
>>
>
> I do not see how VM could help to solve problems with conflicts
> between frameworks. Any feature can be abused.
> Like in case with global namespace, this is something which we should
> (and should be able)
> to deal with at language side.
> But apart from dark sides, look at bright sides as well: different
> frameworks can actually share same property, if they need to do so.
>
> And last thing, consider Javascript and Self (and many other dynamic
> languages), which allow you to have as many properties per object as
> you like, and seems like living quite well with it.

But those are different languages.

> Except that since it is their "default" setup, it is of course much
> less efficient comparing to having a fixed "known" instance variables
> per instance.
> But look what V8 guys did: they actually came to same idea, but from
> another side.

What do you mean by "same idea"? IIRC they created classes for js objects 
behind the scenes.


Levente

>
> So, there is nothing new in what i proposing: we can have the best of
> two worlds.
>
> P.S. Oh yes, i did not suggested that immutability bit has to be
> stored in additional properties slot,
> because checking it will be even less effective than using bit in header.
> I just wanted to indicate that actually immutability is a property,
> and as well as hash has the same "external" nature to all objects:
> these properties are meaningful only to some certain frameworks/layers
> in a system,
> but not globally to every possible class.
>
>> Levente
>>
>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>
>
>
> -- 
> Best regards,
> Igor Stasenko.
>


More information about the Vm-dev mailing list