[Vm-dev] Re: Immutability, newspeak (was: Vm-dev post from jbaptiste.arnaud@gmail.com requires approval)

[Eliot Miranda]

Igor,

On Wed, Jun 9, 2010 at 1:34 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 9 June 2010 23:24, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Wed, Jun 9, 2010 at 1:14 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> On 9 June 2010 22:57, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Jun 9, 2010 at 12:34 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >> >>
> >> >> On 9 June 2010 21:51, Andreas Raab <andreas.raab at gmx.de> wrote:
> >> >> >
> >> >> > On 6/8/2010 7:41 AM, David T. Lewis wrote:
> >> >> >>
> >> >> >> What do the VM developers think with respect adopting the VM
> changes?
> >> >> >> The immutability bit is a scarce resource. Is it OK to allocate it
> >> >> >> for this purpose or are there likely to be other projects
> interested
> >> >> >> in using it for other reasons?
> >> >> >
> >> >> > Oh, and one thing that I'm just realizing is that by far the
> biggest impact
> >> >> > of immutability is in primitives and plugins. All primitives in all
> plugins
> >> >> > must be rewritten to test for mutability of the objects they store
> into
> >> >> > before this can work reliably. Ouch.
> >> >> >
> >> >>
> >> >> Yeah. I told before, that i'm not a big fan of making VM more and
> more clever.
> >> >> It is because 'clever' is synonym to 'complexity'.
> >> >>
> >> >> I'd rather focus on providing immutability at language side, instead
> >> >> of implementing it
> >> >> primitively.
> >> >>
> >> >> However, i am thinking, if there could be good alternatives to
> >> >> immutability bit in object header.
> >> >> One idea is to add this bit on a per-class basis, not on a
> per-instance basis.
> >> >>
> >> >> Then VM could check immutability during a method lookup and throw
> >> >> exception before entering method(s) which can mutate
> >> >> an instance of such class. But then we should also divide
> >> >> primitives/methods on those which can and can't
> >> >> mutate the object's state, which is also a lot of work.
> >> >
> >> > You think its cheap to scan methods for mutablity??  Remember you have
> to identify inst var writes not just mutating primitives like at:put:.
> >> >
> >> >>
> >> >> Checking before entering method potentially will have much less
> impact
> >> >> on performance, because it is not so fine granular as per each write.
> >> >
> >> > I don't think so.  Not without a JIT to cache the scanning of methods
> for mutators.
> >>
> >> It could be done at compilation stage. No need  to scan bytecode at run
> time. :)
> >> I referred to checks as 'if this method perform writes to receiver'.
> >> But not 'if this method performs writes anywhere'.
> >>
> >> >This scheme also only works for methods, not for code in plugins.
> >>
> >> Sure. Plugins is another story.
> >>
> >> > The above is speculation.  The immutability scheme I'm discussing is
> real and known to work in practice.
> >> >
> >> > BTW, I implemented a per-class scheme ages ago in above BrouHaHa (in a
> Smalltalk-80 v2.3 derived image) to provide immutable literals.  It worked
> badly for literals since 'foo' class ~~ 'foo' copy class (one needs an
> ImmutableByteString class and a ByteString class for every class one wants
> to make immutable).
> >>
> >> I don't see this as a disadvantage.
> >> Mutable and immutable objects are clearly having different behavior.
> >> And in smalltalk the only way to get two objects with different
> >> behavior is to use different classes for them. No?
> >>
> >> > Lots of the system was affected by the change since the store string
> of a mutable string ends up being
> >> >     'the immutable string literal' copy
> >> > to get a mutable string.
> >>
> >> Err.. not sure i understood what 'store string of a mutable string'
> means.
> >>
> >> What is the point in having an immutable objects then, if you
> >> automatically copying them at write attempt?
> >> I don't see any gains comparing to:
> >>
> >> ' the mutable string' copy at: 1 put: $x
> >>
> >>
> >> > Our experience with VisualWorks was different.  Lots of methods had to
> be changed because they were attempting to update immutable literals.  There
> were lots of
> >> >     stream := '' writeStream.
> >> > throughout the system which had not been noticed.  But unlike the
> BrouHaHa experience the changes only affected violations of immutability.
>  In BrouHaHa the changes were due to trying to accommodate the clumsy
> class-based scheme.
> >>
> >> I am really interested to hear more about BrouHaHa implementation,
> >> because i like this approach. So, i'd like to hear,
> >> why you considering it clumsy.
> >
> > Consider the file-out of a method category stamp:
> > !FooClass methodsFor: 'category' stamp: 'initials date'!
> > Since a literal string is immutable and has a different class to a normal
> mutable string then in the original Smalltalk-80 code without changing the
> file-out code to take account of immutability the above printed out as
> > !FooClass methodsFor: 'category' copy stamp: 'initials date' copy!
> > So many places which used storeString et al with literals that had
> mutable duals (string and array literals) had to be rewritten to produce the
> old format.  Clumsy.
>
> I am confused by this example. Why one should file out !FooClass
> methodsFor: 'category' copy stamp: 'initials date' copy!
> instead of old one?
> I am agree, that this will require a sizeable effort for introducing
> the immutable subclasses.
> But in this way, it is reflected in a language, instead of implicit
> and hidden VM checks.
>

In a class-based immutability scheme its likely that something analogous to
the following is true:

'a literal string' class == LiteralByteString
'a literal string' copy class == ByteString

If so then its likely that
      'a literal string' storeString
is the characters
      'a literal string'
but that
      (ByteString withAll: 'a literal string') storeString
(i.e. a mutable form of the string 'a literal string')
is the characters
       'a literal string' copy
since we want
    (Compiler evaluate: aThing storeString) class = aThing class
to be true.

So if you go for a class-based immutable literal scheme you're torn between
wanting a mutable string to print as a literal string and wanting literals
to be immutable and normal strings not to be.


> > But you don't need take my word for it.  Try it and see.  Implement e.g.
> LiteralByteString & LiteralByteArray, modify the compiler and see how things
> go.
>
> :)
>

I'm serious.  Its not hard.  Do the experiment.  Better than waffling about
thinking it's a better scheme without any experience.  My experience was
that it was easy to implement and lots of things broke, but the things that
broke were innocent bystanders.  My experience with the immutability bit was
that it was a little tricky to implement in the VM and reasonably easy to
apply in the image and lots of things broke, but the things that broke were
broken and few innocent bystanders were hurt.


best,
Eliot

>
> > cheers,
> > Eliot
> >>
>
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100609/3b6a995b/attachment-0001.htm