[squeak-dev] Re: immutibility
siguctua at gmail.com
Thu Apr 1 04:31:54 UTC 2010
On 1 April 2010 06:06, Colin Putney <cputney at wiresong.ca> wrote:
> On 2010-03-31, at 8:24 AM, Bert Freudenberg wrote:
>> On 31.03.2010, at 17:23, Andreas Raab wrote:
>>> On 3/31/2010 8:13 AM, Bert Freudenberg wrote:
>>>> Show me a single place that would break in a real-world use-case.
>>>> In fact, #become: is rarely used in Squeak because of its inherent slowness caused by our direct-pointer object model. And those rare places I can think of would work just fine.
>>> I think there is one, and only one, place where #become: is intrinsically required: Changing class shape.
>> Thought about that. Should be fine.
> So you're saying you think it's OK that immutable objects don't get migrated to the new version of the class? I suppose that conforms to a strict interpretation of the of the term "immutable" - neither state nor behaviour may be change.
> At some point though, such a strict interpretation isn't very useful. An object that can't change state, can't change behaviour, can't refer to mutable objects, and can't become mutable again is certainly worth of the term, but it's also useless from a practical point of view. Has anyone proposed a use case for this sort of immutability? If not, why insist on defining the term so tightly?
> As far as I'm aware, the use cases for immutability, loosely defined, are as follows:
> (a) Literals. If the compiler makes objects immutable before putting them in the literal frame of a method, we can be sure that the state of the object when the method is activated is the same as what appears in the source code. This is certainly nice. Mutability of literals hasn't been a problem so far, though, so it's not crucial.
> (b) Write Barrier. Immutability as implemented in, for example VW, allows object mutation to be efficiently tracked, which is handy for persisting objects outside the image, or synchronizing their state between images.
> (c) Concurrency. The tricky thing about concurrency is shared mutable state. If it's possible to make objects immutable, it's then possible to share them safely between units of concurrency - Processes, Islands, images etc. When sending state between units of concurrency, immutable objects can often be transmitted more efficiently.
> (d) Garbage Collection. If there are enough immutable objects in the image, it might be possible to improve the efficiency of the garbage collector. Have an "immutable space" and cache all the pointers back into mutable space. Or something. Or the "Shared Perm Space" thing that VW used to have.
> Any other ideas?
> For me, (b) and (c) are the interesting cases. Seaside apps almost always need to persist data in some way, and (b) would make this a lot easier and more efficient. (c) is maybe less clear cut, but in a lot of ways it's more interesting. I like the general trend in Squeak toward event loop concurrency, rather than classical Processes & Semaphores. Immutability would enable more experimentation in this area.
> Perhaps if we focused on these use cases, we'd have a more productive discussion. It may be that VM-level immutability isn't useful enough to be worth the effort to implement and support. But if it *is* worthwhile, it'll be because of what it let's us do, rather than how semantically correct our definition of immutability is.
For concurrency.. perhaps.
But i'd say that most problems of concurrency is sharing a mutable
state, not immutable one, because in most cases its trivial to define
a shared static state in your application and make sure it doesn't
Yes, it would help detecting a *trivial* problems at initial stages of
development, and exchange the immutable data more efficiently, but
again, most of computational tasks anyways dealing with mutable state,
and i don't see how immutability could help in this regard.
What i mean that once you detect immutable object - you can simply
pass a pointer (or copy data, whatever). Cool! But once you detect
that you wanna share a mutable object between islands/images/threads -
you still having the very same concurrency problems as before. And so,
a real problem still is yours :)
I see it as a form of generational GC specialization. Yes, it could
improve GC performance. But why only for immutables?
I think that you could achive nearly same effect by simply adding 1
more generation to GC model without need of separating objects on
ones, which can mutate and ones which can't.
So, for me, there is only (a) and (b) seem useful with an easily
Igor Stasenko AKA sig.
More information about the Squeak-dev