[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Igor Stasenko]

On 14 June 2012 20:31, Colin Putney <colin at wiresong.com> wrote:
>
> Igor wrote:
>
>> In theory, of course we can enforce anything, but in practice that
>> means a lot of complex code with many checks at VM side.. This is not
>> what i like to see in a first place, especially knowing that Squeak
>> lived well so far without any immutability and it does not feels like
>> we miss it badly.
>
> Andreas responded:
>
>> I absolutely do. There were several situations (for example in Croquet
>> and at Teleplace) where we changed our designs to the worse merely due
>> to the lack of immutability support. The main thing that immutability
>> fixes is to prevent accidental modifications of objects thought to be
>> immutable (method literals for example), which when they happen are
>> *extremely* hard to find. But it also gives rise to many other
>> interesting techniques (read-only transactions etc).
>
> I have to agree with Andreas here. I've used immutability to good
> effect in VisualWorks, and run into several situations where I wanted
> it in Squeak and had to make do with a work around. Avi's WriteBarrier
> package is one of those workarounds.
>
> To be honest, I'm a little puzzled by the resistance to immutability.

Well, my main take against it, that smalltalk lived quite well without
it so far.
If it would be so crucial, then it would be there long ago, (even back
in ST'80) isn't?

>From a purist's perspective, it also doesn't looks like a good move.
Because originally we start from quite simple and universal:
- everything is an object
then we added
- all objects are instances of some class

but now we adding:
all objects  *also* have identity hash
all objects *also* have immutability bit

today we have few of those *also's* , tomorrow we will find the need
for 50 more, because there's virtually
no limit about what additional properties we may want to have per object..

And so, an only logical step, as to me was to do it for real:
I proposed to add a slot for arbitrary properties per object, is
simply a unification of the above,
so you can state:
- all objects *also* have at least one property slot, which can be
used by language to store arbitrary properties per object (or at least
one), *without* a need from object in question to have a direct
knowledge
about the nature of these properties (in contrast to instance
variables, immutability, hash etc).

That also means that VM don't needs to know anything about those
properties as well, which directly converts into less code and less
complexity.


> It's not like this is a new idea with unclear semantics or unknown
> utility. The VisualWorks implementation is simple and useful.
> VisualWorks is still the fastest Smalltalk around, so the performance
> impact can't be *too* high. VisualWorks is fairly similar to Squeak,
> so it's not unreasonable to use it as a model for considering
> immutability in Squeak.
>
> Now, maybe there really are problems with the VW, VA or Gemstone
> implementations, and if so, let's hear about them. "It's not
> necessary" isn't a good argument, because nothing is really
> necessary—assembly works fine. What are the costs, benefits and
> trade-offs of VM-supported immutability?
>

For me the main cost is, of course, performance. If we take our
existing images (which have no notion
about immutability) they will perform slower on same hardware.
We can turn this cons into pros, only when we will start using
immutability around the places..
and here is where fun stuff begins: you cannot manage immutability
state over more than ONE framework.
So you will have to invent more complex schemes like mentioned
"immutability managers" etc..

Anyways, the fact is, that most software will still won't use it
anyways, but you will keep paying the price of having it.
It's like introducing a new tax "to fund an activities to keep
homeowner's lawns green and clean", and taking it from everyone, even
from those who don't have own lawn and even don't own the house :)


> Colin


-- 
Best regards,
Igor Stasenko.