<div dir="ltr"><span style="font-size:12.8px"> immutablity - and immutable bitblit?</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Depending on how paranoid you want to be with the accounting, should you also have an ungarbagecollector bit as well, so that you can't forget the entry and re-enter it later?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Just curious,</span></div><div><span style="font-size:12.8px">cbc</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 7:34 AM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 11.11.2015, at 16:21, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
><br>
> Hi Tobias,<br>
><br>
>> On Nov 11, 2015, at 2:50 AM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>><br>
>><br>
>> Hi all,<br>
>><br>
>> I just want to add my 2ct to this.<br>
>> I'd rather like to habe the immutability bit be one-shot,<br>
>> non-resettable, ie, an immutable object stays that way its entire lifetime.<br>
>> I know that conflicts with the idea of the lightweight read barrier, but<br>
>> I think this would be worthwhile for value classes :)<br>
>><br>
>> Can we find a compromise here?<br>
><br>
> 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.<br>
><br>
<br>
</span>I understand it is important, so maybe we should look at how make a read barrier a proper citizen in our town?<br>
<br>
<br>
(Ramblings:<br>
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).<br>
Also, when immutable objects are actually immutable, I can rely on that fact; nobody can change them under the hood.<br>
I as a VM developer then can speculate on that fact.<br>
<br>
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…)<br>
<br>
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…<br>
I can live with a write-lock bit :D<br>
<br>
<br>
Best regards<br>
-Tobias<br>
<br>
(my fingers always want to write immutablity… does anyone know that word?)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
>><br>
>> Best regards<br>
>> -Tobias<br>
>><br>
>>> On 10.11.2015, at 17:35, Ryan Macnak <<a href="mailto:rmacnak@gmail.com">rmacnak@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Clement,<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Ryan<br>
>>><br>
>>> On Tue, Nov 10, 2015 at 6:17 AM, Clément Bera <<a href="mailto:bera.clement@gmail.com">bera.clement@gmail.com</a>> wrote:<br>
>>><br>
>>> Hello everyone,<br>
>>><br>
>>> I tried to understand how immutability is implemented in the CogVM (NewSpeak flavor). I have some questions:<br>
>>><br>
>>> - Does it actually work and is it used ?<br>
>>> - 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.<br>
>>> - 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 ?<br>
>>><br>
>>> Thanks !<br>
<br>
<br>
</div></div></blockquote></div><br></div>