<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 12:12 PM, Levente Uzonyi <span dir="ltr">&lt;<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>On Mon, 27 Oct 2014, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     So you would set the bit for the CompiledMethod and all literals (including sub-arrays, floats, integers, booleans etc)?<br>
</blockquote>
<br>
The literals, definitely.  Whether the bit is set for compiled methods or not depends on things like how easy you want to be able to update the source pointer or add/delete properties.<br>
</blockquote>
<br>
If the CompiledMethod itself is not immutable, then one can replace its top level literals easily.<br>
If it&#39;s immutable, then the system will face all kind of problems, like adding the correct trailer during method installation.<br>
You could say &quot;no problem, I&#39;ll use #becomeForward: to do it, it&#39;s fast in Spur&quot;, but that&#39;s what my other question is about.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     Does the set immutability bit also mean that the object can&#39;t be swapped with #become:?<br>
</blockquote>
<br>
That&#39;s debatable, but in VW we disallowed two-way become: and allowed one-way become: for immutables.  I think that&#39;s right.  one-way become is about references to objects, two-way become is about changing objects themselves. <br>
</blockquote>
<br>
It&#39;s not about #become: vs #becomeForward:. If objects with the immutable bit set can be replaced with #becomeForward:, then the literals are not really immutable, because they can be changed.<br>
If you also want to check if there are immutable objects pointing to the object which is about to be replaced, then the performance of #becomeForward: would become as slow as in the non-Spur VMs.<br></blockquote><div><br></div><div>I disagree.  It&#39;s about an incremental improvement.  A per-object immutability bit used to protect against direct alteration of literals works.  Right now there&#39;s nothing to stop one recompiling a method, and per-object immutability doesn&#39;t change that.  So mutable compiled methods are tolerable (at least in VW we kept methods mutable).  But having the bit stop direct modification of literals is goodness, not to be avoided because it doesn&#39;t prevent more exotic modification via become.</div><div><br></div></div>-- <br>best,<div>Eliot</div>
</div></div>