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

Wed Jun 13 18:46:09 UTC 2012

re immutability I'd like to point out that VisualWorks has had immutability
for nearly seven years now, VisualAge has had immutability for even longer,
and its proved straight-forward.

- literals are finally immutable, no accidentally changing literals and
finding out that the application behaves inexplicably because the source no
longer matches the method

- GemStone makes efficient use of the write barrier for its object paging
facilities

- this is done with a framework that allows different applications to
register managers for different objects so that the VM-level immutability
support can be shared amongst different clients (GemStone, debug traps, etc)

So adding immutability isn't adding some radical poorly understood feature,
but instead adding something with proven utility that adds safety.

In the new object format my design philosophy is similar to that of Cog.
 Be conservative; make sure the existing system is supported well.  No
experiments; this is a production VM (but that doesn't preclude supporting
experiments, e.g. using Stefan's excellent idea of supporting an optional
extra header word).  Extend for performance; adding 64-bit support,
immediate floats and immediate characters all improve performance, as does
lazy become and the space and time savings due to the new object
representation itself (class index instead of class reference).

None of this prevents folks from doing more radical things with it.  But
I'm not interested in implementing an experiment, I'm interested in
engineering a significantly faster and more scaleable VM. Hence for me,
forcing a become to add an identityHash is too experimental and risky.  I
know that the elements I've expressed in the design work; they're all ideas
that other systems have used, even if lazy become hasn't been used in
Smalltalk VMs before (AFAIA).

On Wed, Jun 13, 2012 at 9:01 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 13 June 2012 16:32, Andreas Raab <Andreas.Raab at gmx.de> wrote:
> >
> > Igor wrote:
> >
> > On 13 June 2012 15:16, Andreas Raab <Andreas.Raab at gmx.de> wrote:
> >>
> >>
> >> On 13 June 2012 09:41, Bert Freudenberg <bert at freudenbergs.de> wrote:
> >>>
> >>> On 2012-06-13, at 05:27, Igor Stasenko wrote:
> >>>
> >>>> Another (open) question, is how to deal with immutability in presence
> >>>> of  become, i.e.:
> >>>>
> >>>> mutableCopy := immutableObject shallowCopy.
> >>>> immutableObject becomeForward: mutableCopy.
> >>>>
> >>>> such kind of things making immutability useless for protecting some
> >>>> critical parts of object memory,
> >>>> like preventing modification of compiled method literals:
> >>>>  yes you cannot change the immutable object, but you can replace all
> >>>> pointers to it with it's own mutable copy, which is equivalent to
> >>>> making it mutable again.
> >>>
> >>>
> >>> Why should the VM allow become of an immutable object?
> >>>
> >>
> >> You can disallow this. But you can only make it harder: i can do it
> >> manually - take all objects pointing to immutable one and replace the
> >> pointer to it with it's mutable copy. And it is completely legal,
> >> except that it will be a bit harder, since done not by primitive.
> >>
> >>
> >> You are confusing something here. Become is just a "fancier form" of
> assignment that you could in fact write without a primitive by enumerating
> all the references to an object. If you keep that in mind it is obvious
> that since assigning an immutable *to* a variable is never a problem using
> become *with* an immutable as argument is neither since in both cases the
> immutable remains immutable.
> >>
> >
> > But you just make it harder.. what prevents me from modifying all
> > pointers to immutable(a) which holds a pointer to target immutable(t),
> > by mutable object (b) with replaced references to mutable (t')?
> >
> >
> > Absolutely nothing. Why should it? Assuming that all your "pointers to
> immutable a" are mutable themselves you can absolutely change them. Go
> right ahead. You *can* replace an immutable by a mutable object, it's
> trivial:
> >
> >   value := Object new beImmutable.
> >   value := value asMutableCopy.
> >
> > See, done. So where is the problem? Whether you write it like that or
> whether you write it like here:
> >
> >   value := Object new beImmutable.
> >   value := value become: value asMutableCopy.
> >
> > is entirely irrelevant. It doesn't change the fact that the original
> object is still immutable after the operation and that's the only thing
> that counts for the VM operation. Of course the following would be somewhat
> different:
> >
> >   immutable := (#abc -> Object new) asImmutable.
> >   value := immutable value beImmutable.                   "making the
> value immutable"
> >   value := value become: value asMutableCopy.
> >
> > In this case, the following assertions should hold:
> >
> >   self deny: value == immutable value. "assoc was frozen, no changing
> its value"
> >   self assert: value isMutable.
> >   self deny: immutable value isImmutable.
> >
> > So this all works out just fine. BTW, I think that discussing the use of
> become for hacking into the system is beyond the scope of this discussion.
> Become is used in very few situations and its semantics are necessarily
> such that one can do bad things with it. Duly noted, let's move on.
> >
> >
> >> The real question that arises is whether become should be allowed to
> change the *contents* of an immutable object. Personally, I think it should
> not, but this has some side effects that require fixing such as class
> migration which really should have a separate primitive to update its
> instances after reshape - the rules for this *should* include changing
> immutables unless you want to change the system to deal with multiple
> concurrent class versions (much pain down that path).
> >>
> >
> > This is where i usually stop. IMO this is already showing too much
> > costs (to my taste) of introducing such restrictions and maintaining
> > them. I would ask first, is this worth an effort, if it so costly in
> > terms of implementation?
> > 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.
> >
> >
> > 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.
>
> I finding this very weak argument. You are talking about developing
> project and bug fixing.. Yes i agree immutability can be useful for
> debugging. But for deployed & well tested applications?
> Once you found all bugs, and deploy your application, do you really
> think it is worth paying the price for checking all  write operations,
> when you already made sure that your app will behave correctly?
>
> This is the same scenario as if i build debug version of VM which has
> many assertions and additional checks enabled,
> so i can find what is going on.
> But when you deploy, you disable them for obvious reason -
> performance, and because they don't needed once you prove that all
> preconditions hold, no matter what your code does.
>
> As for *extremely* hard to find, i think first thing which you should
> address in such cases is the complexity
> of your application, to always be able to reason about it's behavior
> and make sure it behaves "deterministically", because if software
> grows too large up to the point that you need such kind of crutches to
> figure out what's happening, immutability alone doesn't solve your
> problems, it can only indicate that you have a problems with your
> design.
>
> > But it also gives rise to many other interesting techniques (read-only
> transactions etc).
> >
>
> Look, we have completely open system in our hands. Do you think it is
> impossible to implement certain things w/o immutability?
>
> > Cheers,
> >   - Andreas
> >
> >
> > For me, if we introduce some feature or want to enforce certain
> > behavior, then there should be very strong reason
> > for doing so, with benefits which clearly outweigh the costs and
> > making some things easier to do, like with arbitrary properties slot
> > - there's very little additional complexity in VM side, and very
> > simple to use at language side, replacing many crippling schemes ,
> > like properties in Morphic , Dependents in Object etc.
> > In contrast, an immutables adds another dimension of complexity to
> > already complex soup in both VM and language sides, and benefits are
> > not so clear, as to me.
> >
> >
> >
> >> Disallowing #become on immutables raising many additional questions:
> >>
> >> what is your action when you need to migrate instances of a class due
> >> to it's reshaping, while some of them are immutable?
> >>
> >>
> >> Class migration should really have its own primitive. If it had, much
> pain could be avoided in migrating classes (see comments in
> ClassBuilder>>update:to:). And then one could decide on the proper policy
> to use for immutables.
> >>
> >> Cheers,
> >>   - Andreas
> >>
> >>
> >> (I bet there is be many other examples, when this will break existing
> >> traditional schemes, like working
> >> with proxies etc).
> >>
> >> I don't wanna spread FUD.. just want to make sure that we ready to
> >> answer for every such question.
> >>
> >>
> >>> - Bert -
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko.
> >>
> >> --
> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> >>
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko.
> >
> >
> >
> >
> > --
> > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
> > Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

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