[squeak-dev] Re: immutibility
cputney at wiresong.ca
Thu Apr 1 05:02:24 UTC 2010
On 2010-03-31, at 9:31 PM, Igor Stasenko wrote:
> 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
> mutating unexpectably.
> 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 :)
IMO the interesting possibilities here are all about concurrency *without* shared mutable state. If objects can be made immutable, the code that manages communication between islands, images, vats etc, can be intelligent about how it handles them. Application-level code still has to manage communications between units of isolation, but its interface with the runtime can get simpler if the runtime can tell what's mutable and what's not. It's about making it easier to implement Islands, etc. in Squeak, not (directly) about making it easier to write an app with such an implementation.
Admittedly, it's not as easy to predict how much of an impact immutability would have in this realm, especially when compared with (b). But I do think it's one of the basic building blocks that would enable experimentation here.
> Perm space.
> 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.
<shrug> Yeah, I was scraping the bottom of the barrel with this one. It's a stretch no matter how you look at it.
> So, for me, there is only (a) and (b) seem useful with an easily
> foreseen impact.
Fair enough, though (c) may have unforeseen impact.
More information about the Squeak-dev