[Vm-dev] Questions related to immutability in Cog

[stephane ducasse]

>> 
>> The VM is agnostic about how the upper levels of the system uses it.  There's nothing to stop you overriding the method that sets the bit, so I think we can have both.  Just remember that the lightweight read barrier is /really/ useful for persistence schemes and that's v important to typical industrial applications.
>> 
> 
> I understand it is important, so maybe we should look at how make a read barrier a proper citizen in our town?
> 
> 
> (Ramblings: 
> My feeling now is that the on/off-immutability is primarily useful for that case (which is fine), but I can imagine cases where immutable immutability is more favourable, like Accounting: when I only can create but not _modify_ any object, no changes are lost (as I, for example, can only create newer versions of an object but not actually modify them).
> Also, when immutable objects are actually immutable, I can rely on that fact; nobody can change them under the hood. 
> I as a VM developer then can speculate on that fact. 
> 
> Well, maybe I also want a stronger concept here (viz. Value classes), and be able to map identity to value equality. But I'd need immutable immutability, nonetheless…)

I would really like to see what you can do with that. 
But I have the impression that we will not have two bits to express both :)

Stef

> 
> So, I'd be more happy if we'd name the temporary immutability "write-locked" or so, because a lock can be lifted, actual immutability is perpetual…
> I can live with a write-lock bit :D
> 
> 
> Best regards
> 	-Tobias
> 
> (my fingers always want to write immutablity… does anyone know that word?)
> 
> 
>>> 
>>> Best regards
>>>  -Tobias
>>> 
>>>> On 10.11.2015, at 17:35, Ryan Macnak <rmacnak at gmail.com> wrote:
>>>> 
>>>> Hi Clement,
>>>> 
>>>> Per object immutability was implemented in the old, pre-Cog Newspeak VM (NewspeakInterpreter). It has not yet been implemented current Cog Newspeak VM (Stack/CoInterpreter + NewspeakVM=true), but the necessary bit is reserved in the object header. It was used as part of an orthogonal synchronization scheme to detect changed objects: mark synchronized objects as immutable, trap on change attempt, add to dirty list and mark as mutable again. A marked object is only shallowly immutable, and its instance variables may contain mutable objects.
>>>> 
>>>> Ryan
>>>> 
>>>> On Tue, Nov 10, 2015 at 6:17 AM, Clément Bera <bera.clement at gmail.com> wrote:
>>>> 
>>>> Hello everyone,
>>>> 
>>>> I tried to understand how immutability is implemented in the CogVM (NewSpeak flavor). I have some questions:
>>>> 
>>>> - Does it actually work and is it used ?
>>>> - Does an object being immutable means that you can't edit its variable fields only or that you can't either edit its instance variables ? Because I don't see any code checking for instance variable stores in the Newspeak interpreter.
>>>> - How does the immutability check works in machine code ? In the Newspeak interpreter there is an immutability check in #at:put: . In the at:put: generated by the JIT (for example CogObjectRepresentationFor32BitSpur) I don't see any immutability check. Did I miss some clever bit trick ? Does the Newspeak spur VMs use the #at:put: machine code version of the primitive ?
>>>> 
>>>> Thanks !

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151111/bedd43ad/attachment.htm