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

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 14 21:49:07 UTC 2012


On Thu, Jun 14, 2012 at 12:14 PM, Igor Stasenko <siguctua at gmail.com> wrote:

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

But it *hasn't*, as evinced by the bugs in the base libraries surfaced by
adding immutablity to VisualWorks (and no doubt to VisualAge as well).


> If it would be so crucial, then it would be there long ago, (even back
> in ST'80) isn't?
>

On a 16-bit machine with 32k objects there were many things that were lived
without.  Would you have us do without ensure: and exceptions and tuples
and closures just because  Smalltalk-80 didn't have them?  What a silly
argument.


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



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120614/b0026410/attachment.htm


More information about the Vm-dev mailing list