[Vm-dev] Re: [Pharo-dev] Should literals be immutable ?

Levente Uzonyi leves at elte.hu
Mon Oct 27 19:12:34 UTC 2014

On Mon, 27 Oct 2014, Eliot Miranda wrote:

>>      So you would set the bit for the CompiledMethod and all literals (including sub-arrays, floats, integers, booleans etc)?
> 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.

If the CompiledMethod itself is not immutable, then one can replace its 
top level literals easily.
If it's immutable, then the system will face all kind of problems, like 
adding the correct trailer during method installation.
You could say "no problem, I'll use #becomeForward: to do it, it's fast in 
Spur", but that's what my other question is about.

>>      Does the set immutability bit also mean that the object can't be swapped with #become:?
> That's debatable, but in VW we disallowed two-way become: and allowed one-way become: for immutables.  I think that's right.  one-way become is about references to objects, two-way become is about changing objects themselves. 

It'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.
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.


More information about the Vm-dev mailing list