On 1 April 2010 08:02, Colin Putney <cputney at wiresong.ca> wrote:
>
> 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.
>

Maybe. I still thinking, that OO approach is much more powerful and flexible.
As easy as,
object replicateIn: island
lets an object to decide how to replicate itself in given
island/environment, whether create a copy or pass as a reference (or
any other form),
without a need of introducing any magic from VM side.
This gives you a direct control over what happens and when.
Bug again, we don't have a model, already implemented and widely used
which employs an immutability in a way you suggested. So, this still
lies in experimental area.
While with DB replication schemes, we already having a real use
examples. So, logically would be to focus on this ones instead.

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



-- 
Best regards,
Igor Stasenko AKA sig.