On Thu, Mar 18, 2010 at 8:23 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 18.03.2010, at 15:51, Colin Putney wrote:
> >
> >
> > On 2010-03-18, at 5:39 AM, Bert Freudenberg wrote:
> >
> >> HO there should be no way to reset the immutable flag. You can implement
> "soft" immutability in the image, but "hard" VM-level immutability needs to
> be permanent, no fiddling possible. Once set, the object stays immutable.
> Only a copy of an immutable object will be mutable again.
> >
> > This would be good for some use cases - literals, for example, but not so
> good for others. One of the common uses of "immutability" is not so much to
> *prevent* mutation, as to control it: databases, concurrency etc. Do you
> have another feature in mind for these cases, or some overriding interest in
> immutable immutability that you want to pursue?
> >
> > Colin
>
>
> Seems to me like two separate issues - one being informed of modifications,
> and one preventing modifications. Immutability to me means the latter. The
> former is more like a write barrier.
>
> With true immutables you can start developing in a mixed object/functional
> style, which would allow interesting optimizations, e.g. for concurrency,
> memoization etc.
>

But the same VM support can allow both styles.  The VM support is a
per-object bit that marks an object as immutable along with modifications to
inst var assign and at:put: primitives to check for the immutability bit,
and a pair of primitives to fetch and set the per-object isImmutable flag.
 If the primitive to set immutablity is removed and replaced with a
primitive that can only enable immutability, or if use of the primitive is
suitably restricted then one can prevent clearing of the flag.  The VM is
the same in oth cases; it simply has to check for the immtability flag on
each write, but above that one can use this as a write-barrier or to
implement "true" immutability.

Note that the cost of checking immutability on each write is quite small in
the at:put: primitives because these must fetch the object header containing
an object's size to do bounds checking, and testing a bit in a register
containng the header merely adds a register operation not a more expensive
read.  It does add to the cost of inst var write, but again the overhead is
not that large because inst var write also involves the GC's write barrier.
 So overall the performance impact is in my experience (VW & Newspeak) < 5%
overall speed decrease for macro benchmarks.

>
> - Bert -
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100318/fc20960f/attachment.htm