<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"><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></blockquote><br>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:<span class="Apple-converted-space"> </span><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.<span class="Apple-converted-space"> </span><br>I as a VM developer then can speculate on that fact.<span class="Apple-converted-space"> </span><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></div></blockquote><div><br></div>I would really like to see what you can do with that. </div><div>But I have the impression that we will not have two bits to express both :)</div><div><br></div><div>Stef</div><div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><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><span class="Apple-tab-span" style="white-space: pre;"> </span>-Tobias<br><br>(my fingers always want to write immutablity… does anyone know that word?)<br><br><br><blockquote type="cite"><blockquote type="cite"><br>Best regards<br> -Tobias<br><br><blockquote type="cite">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 !</blockquote></blockquote></blockquote></div></blockquote></div><br></body></html>