[Vm-dev] Questions related to immutability in Cog

[Tobias Pape]

On 11.11.2015, at 16:21, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 
> Hi Tobias,
> 
>> On Nov 11, 2015, at 2:50 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> 
>> Hi all,
>> 
>> I just want to add my 2ct to this.
>> I'd rather like to habe the immutability bit be one-shot,
>> non-resettable, ie, an immutable object stays that way its entire lifetime.
>> I know that conflicts with the idea of the lightweight read barrier, but
>> I think this would be worthwhile for value classes :)
>> 
>> Can we find a compromise here?
> 
> 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…)

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 !