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

[Igor Stasenko]

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.

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

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.