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

Eliot Miranda eliot.miranda at gmail.com
Mon Oct 27 19:28:40 UTC 2014

On Mon, Oct 27, 2014 at 12:12 PM, Levente Uzonyi <leves at elte.hu> wrote:

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

I disagree.  It's about an incremental improvement.  A per-object
immutability bit used to protect against direct alteration of literals
works.  Right now there's nothing to stop one recompiling a method, and
per-object immutability doesn'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't prevent more exotic modification via become.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141027/50584223/attachment.htm

More information about the Vm-dev mailing list