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

Eliot Miranda eliot.miranda at gmail.com
Wed Jun 9 21:13:43 UTC 2010


On Wed, Jun 9, 2010 at 1:27 PM, stephane ducasse <stephane.ducasse at gmail.com
> wrote:

>
> > You think its cheap to scan methods for mutablity??  Remember you have to
> identify inst var writes not just mutating primitives like at:put:.
>
> in our experimentation on doing a per reference flow of security property
> (pure research) we have to check all the iv store and this is not
> something I would do on a real solution.
>
> I have the impression that the immutability bit can give us an opportunity
> to slowly build a more secure system.
> What I like is that it is simple to understand and we can build alternate
> and enhanced solution. Even if for us it uses a bit that we like to have to
> create strange ideas.
>
> >
> > 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).
>
> Eliot I did not get that why for every class
>
> >  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.
> >
> > 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.
>
> Yes this would be nice to spot such places. I would really like to know
> other cases where immutability helped VW.
> Do you have some anecdotes?
> Since it required an effort to bring that in VW, what was the selling
> argument at that time for getting it into the system?
>

Looking at my old emails it looks like I did it as a skunkworks project in
the VM for fun, based on conversations with Alan Knight and Martin McClure
and probably Steve Dahl.  I was technical lead so I did have some latitude
to do what I thought was right. Once it was done we started using it
internally and while the process was painful as we discovered all the places
where immutable literals were being written to we also thought that it was
in part worth-while precisely because we were finding places where immutable
literals were being written to.  Alan Knight did yeoman's work providing a
UI and underlying machinery to allow one to "turn-off" immutability checking
by having the exception disable immutability, redo the mutation and
continue, or to do the same, reenabling immutability and logging the attempt
to the transcript.  So customers could turn off strict immutability while
they got their code up and running.  The GemStone folks, especially Martin
McLure provided plenty of encouragement.  It delayed the release a little
(in fact ephemerons caused much more problems) but it was one of the two
major VM features of VW 7.


> >  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.
> >
> > cheers,
> > Eliot
> >
> >
> > > Cheers,
> > >  - Andreas
> > >
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100609/ac604136/attachment.htm


More information about the Vm-dev mailing list