<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Chris,</div><div><br><div><br><br><span style="background-color: rgba(255, 255, 255, 0);">_,,,^..^,,,_ (phone)</span></div>On Mar 25, 2018, at 8:26 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On Sun, Mar 25, 2018 at 6:18 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:</span><br><blockquote type="cite"><span>Hi All,</span><br></blockquote><span></span><br><span>Hi Eliot,</span><br><span></span><br><span>Congratulations on the enhancement. As developer of Magma, I'm</span><br><span>interested in learning more about it as a possible alternative to the</span><br><span>WriteBarrier. How does it work?</span><br></div></blockquote><div><br></div>There is a per-object flag (a bit in the object header) that if set prevents modification. The bit is controlled by Object>>#setIsReadOnlyObject: with <span style="background-color: rgba(255, 255, 255, 0);">Object>>#</span>beReadOnlyObject as a convenience. <span style="background-color: rgba(255, 255, 255, 0);">Object>>#beReadOnlyObject is the getter. By default the bit is off (new objects are mutable). The Compiler modification sets the bit for method literals (literal strings, symbols, arrays, byte arrays and boxed floats). The facility may also be used for </span><div>- an object-to-database mapping system</div><div>-debugging</div><div>etc<br><div><br><blockquote type="cite"><div><span></span><br><span>First, it might help me to understand what _your_ primary motivation</span><br><span>for proposing to make various entire classes of objects read-only by</span><br><span>default? </span></div></blockquote><div><br></div>I have proposed no such thing. You have misunderstood :-)</div><div><br><blockquote type="cite"><div><span> As you found from running the tests, the few cases that</span><br><span>modified literals were doing it intentionally. My guess is that more</span><br><span>read-only objects allows the VM to run a lot faster, is that right?</span><br><span>But my hope was that this capability would be provided with</span><br><span>granularity at the object-level, not necessarily the class level.</span><br><span></span><br><blockquote type="cite"><span> the VM now has support for read only objects, and the first logical</span><br></blockquote><blockquote type="cite"><span>application is for literals, making boxed floats, strings, symbols, arrays</span><br></blockquote><blockquote type="cite"><span>and byte arrays read-only.</span><br></blockquote><span></span><br><span>Wow, Arrays and ByteArrays too? Magma's core Buffer classes all use</span><br><span>ByteArray's internally to represent and update their state. Ouch!</span><br></div></blockquote><div><br></div>No, no, no, no :-). Only _literal_ instances of these.</div><div><br><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>Doing so is trivial; only two methods need to be</span><br></blockquote><blockquote type="cite"><span>modified (see attached). AFAIA little or no core code is broken by making</span><br></blockquote><blockquote type="cite"><span>literals read-only. However, when I ran the test suite with read-only</span><br></blockquote><blockquote type="cite"><span>literals in place, several tests were broken. These are things like</span><br></blockquote><blockquote type="cite"><span>creating null-terminated strings for testing OSProcess, by replacing spaces</span><br></blockquote><blockquote type="cite"><span>in string literals with zeros, etc.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>When we added read-only literals to VisualWorks in something like vw7.0 the</span><br></blockquote><blockquote type="cite"><span>balance of opinion was that we should not break user code. Hence we</span><br></blockquote><blockquote type="cite"><span>implemented a preference scheme with three states:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- By default, an attempt to modify a read-only literal would silently make</span><br></blockquote><blockquote type="cite"><span>the literal mutable temporarily,update it and then reenable read-onlyness.</span><br></blockquote><span></span><br><span>Magma uses previously-loaded ByteArray's and replaces their contents,</span><br><span>field by field, via ByteArray>>#uint:at:put:. It runs this method</span><br><span>more than any other in the image -- millions and millions of times.</span><br><span>The performance of this method is very important for Magma.</span><br></div></blockquote><div><br></div>And why on earth would I try and introduce something that would break this?</div><div><br></div><div><br><blockquote type="cite"><div><span></span><blockquote type="cite"><span>- A second state would issue a warning to the transcript, while doing what</span><br></blockquote><blockquote type="cite"><span>the default did.</span><br></blockquote><span></span><br><span>I'm reading that and imagining a low level primitive like</span><br><span>Array>>#at:put: having a reference or signal to the Transcript that</span><br><span>runs *every single time*? That can't be true. Surely the "preference</span><br><span>scheme" you mentioned must've been more sophisticated than global</span><br><span>Preference values. Something more dynamic and simple, like "myObject</span><br><span>beReadOnly: true"...? Then applications -- including the IDE -- can</span><br><span>handle AttemptToModifyReadOnlyObject as needed.</span><br><span></span><br><blockquote type="cite"><span>- The third state would raise an error</span><br></blockquote><span></span><br><span>In the process of raising that error, is there any danger of</span><br><span>encountering a place in the debugger code which attempted to modify</span><br><span>another Array, thus causing it to re-enter the original error-raising</span><br><span>code to raise yet another error? It seems like a pretty low-level</span><br><span>thing to have to guard against...</span><br><span></span><br><blockquote type="cite"><span>Remember that all one needs to do to fix code that modifies literals is to</span><br></blockquote><blockquote type="cite"><span>send copy to the literal before modifying the copy, since copies of</span><br></blockquote><blockquote type="cite"><span>read-only literals are mutable.</span><br></blockquote><span></span><br><span>I hope we are not confusing the intermal representation of objects</span><br><span>being bytes with whether those objects are literals or not. If a</span><br><span>program sees fit to modify a "literal", techincally is not a literal,</span><br><span>but a variable, right? Dave's case sounds like a true literal, but</span><br><span>I'm saying I have applications which update bitmap forms in real time.</span><br><span>Artists paint on SketchMorphs.. I presume you don't mean for _these_</span><br><span>cases to need to make constant copies...</span><br><span></span><br><blockquote type="cite"><span>I was on the side of only raising an error, but was overruled :-). I wonder</span><br></blockquote><blockquote type="cite"><span>what this community thinks. If there are strong views that user code should</span><br></blockquote><blockquote type="cite"><span>continue to function unchanged (even though it is modifying literals, which</span><br></blockquote><blockquote type="cite"><span>is so so wrong :-) ) I'm happy to implement a scheme similar to that for</span><br></blockquote><blockquote type="cite"><span>VisualWorks. But I'd rather not have to and simply have people fix their</span><br></blockquote><blockquote type="cite"><span>code within a system that raises an error whenever an attempt is made to</span><br></blockquote><blockquote type="cite"><span>modify a literal, and is as simple as possible, but no simpler ;-)</span><br></blockquote><blockquote type="cite"><span>Thoughts, opinions?</span><br></blockquote><span></span><br><span>Instead of introducing new assumptions and breaking old code, I</span><br><span>suggest people writing which explicitly turn ON read-only'ness, for</span><br><span>the objects they want preserving legacy expectations about Smalltalk</span><br><span>as well as the operation of legacy applications. IMO, any</span><br><span>introduction of immutability at the class-level should be turned off</span><br><span>by default. Make it powerful but not painful.</span><br><span></span><br><span>It would help tremendously to know what you want to accomplish and how</span><br><span>the new API works.</span><br></div></blockquote><div><br></div>We have been discussing this for a while now. Clément even wrote a paper</div><div><br></div><div><a href="https://hal.archives-ouvertes.fr/hal-01356338/document">https://hal.archives-ouvertes.fr/hal-01356338/document</a></div><div><br><blockquote type="cite"><div><span></span><br><span>Regards,</span><br><span> Chris</span><br><span></span><br></div></blockquote></div></div></body></html>