[Vm-dev] Re: Immutability, newspeak (was: Vm-dev post from jbaptiste.arnaud@gmail.com requires approval)

Eliot Miranda eliot.miranda at gmail.com
Wed Jun 9 18:40:01 UTC 2010


On Wed, Jun 9, 2010 at 10:56 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> On 6/9/2010 9:22 AM, Eliot Miranda wrote:
>
>> It's much more general purpose than OODBs.  Immutable literals and
>> immutable numerics are very nice to have.  Lazy copying in mutable
>> structures is useful in general.  A number of other dialects have an
>> immutability bit and it has carried its weight there.
>>
>
> In what kinds of applications?
>
> I have two major concerns about your arguments. One is that any kind of
> "lazy copying" relies on a fast become which we don't have. So this entire
> line of applications is probably moot as far as I can tell (correct me if
> I'm wrong but I don't see how lazy copying can work without fast become).
>

Here's a sketch of how to do this without a fast become.  Any client of a
lazily copied data structure puts an exception handler at some point around
their ruse of the data structure.  They catch the immutability exception and
coordinate with the data structure to update their reference to the data to
a copy  So instead of the data structure managing things internally there's
some sharing.  Something like

    [sink store: self data]
        on: NoModificationError
        do: [:ex|
              (sink ownsImmutableIn: ex) ifFalse:
                  [ex pass].
              sink := sink copyOnWrite ex.
              ex retry]

THis kind of linkage is clumsy, which is why one constructs a per-object
policy scheme where on can attach actions to attempts to update specific
objects.  In this approach sink (and any necessary substructure) would have
been registered with some kind of policy object (an immutability manager)
that would take case of sending messages to the client to get it to update
its reference to sink and retry the operation.  So with prior registration
(which could be folded into the instance creation code for sink) the api
then becomes

    sink store: data

with the exception handling managed in the background.

Secondly, for concurrency uses (which is the aspect that interests me most)
> the "kind" of immutability proposed here is wrong. What's proposed here is a
> one-level immutability which is really more a kind of write barrier, i.e.,
> it gets turned on, then it gets caught, then it gets turned off, and is
> written to anyway. For concurrency, you need immutability that is a)
> transitive (i.e., freezes an entire object graph) and b) irreversible (i.e.,
> sealing the object graph).
>

That's fine and one can build deep immutability above the shallow
immutability that the immutable bit provides.  All one needs to do is
traverse the object graph, setting the immutability bit.  You might want to
carefully control unsetting the immutability bit so that its hard to
inadvertently turn off immutability in substructure to get b).  But in any
case turning off immutability on something that is immutable is never
 something that's done lightly.

I have at least discussed using shallow immutability to implement deep
immutability with Gilad for Newspeak and he hasn't yet said it can't be done
this way.

Note tat deep immutability is a tricky issue.  Is the class of a deeply
immutable object immutable or can one still add methods to it?  What happens
(with both shallow and deep immutability) if one tries to add an instance
variable to a class that has immutable instances? What if one wants a mostly
deeply immutable data structure that contains e.g. a mutable query cache
that memos the most recent N results of some expensive query?  Exactly what
parts of a data structure should be immutable when is typically application
and data structure dependent and some blanket deep immutability scheme in
the VM is likely to be too inflexible.  A simple per-object bit which has
simple semantics and can serve in many different uses is flexible enough, at
least if 15 years of experience with VisualAge and 10 years of experience
with VW is meaningful.

In terms of general applicability, I would much prefer the latter (it
> matters not for immutable literals which kind is used) but I don't see how
> these different forms of immutability can be reconciled without yet another
> header bit. But if you're in favor of one, you can hardly be against the
> other, no?
>

I don't see that at the VM level two header bits gains you anything.  You're
talking about a policy issue above the VM.  One bit is all the VM needs to
implement the necessary mechanism.   Policy at the image level can then
manage the immutability bit to provide myriad schemes.


>
> So should we add two header bits for immutability instead of one? What
> concerns me here is that any use of immutability appears to be requiring yet
> another header bit - a sign that we thoroughly do not understand what
> immutability is and how it should be implemented. Thus my feeling that
> throwing header bits at the problem is the wrong direction.


Agreed.  I'm not proposing throwing bits at the problem.  One bit's enough.
 Its up to the image level to design a good framework around the basic VM
facility, and that's been done already.



>  In short, scarce resource issues such as header bits are solvable (by
>> reimplementing to make more available), immutability is much more
>> generally useful than OODB interfaces, so (at least form me) this is
>> good use of something lying fallow.
>>
>
> I'm not strongly opposed to it but header bits *are* a scarce resource so
> their allocation should be done carefully as well as the choice of
> semantics. I can say for sure that I would feel *much* better if there was a
> customer who'd say "yes, this is exactly what I need, the semantics is
> precisely right for what I need it for" instead of just "Oooooohhhh,
> immutability, cooooool" (which is all I'm hearing).
>

While some people might be saying "it's cool" I hear the GemStone folks
saying "we much prefer using the immutability bit than rewriting code.  the
immutability bit has worked much better in practice", and GemStone has
plenty of customers who don't have to worry about the issue because GemStone
has done all the work for them. I don't hear anyone from VisualAge and
VisualWorks saying "It's a bad idea, it's had a deleterious effect on
performance".  But there's a modicum of FUD here ;)  (*)

(*) just joking

best,
Eliot

>
> Cheers,
>  - Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100609/a8daea65/attachment-0001.htm


More information about the Vm-dev mailing list