[Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs

Eliot Miranda eliot.miranda at gmail.com
Sun May 8 18:30:39 UTC 2011


On Sun, May 8, 2011 at 12:21 AM, stephane ducasse <
stephane.ducasse at gmail.com> wrote:

>
> Hi Stephane,
> >
> > On Sat, May 7, 2011 at 1:35 AM, stephane ducasse <
> stephane.ducasse at gmail.com> wrote:
> >
> > Eliot
> >
> > may be this is because of bad communication medium but each time somebody
> is mentioning something
> > not really working your main messages over the months is do not fix it.
> > I do not think that this is really the way to build a community around
> Cog.
> >
> > You need to understand the technical issue here before you can say that
> I'm saying "do not fix it".  I am /sure/ that there is no bug here to be
> fixed, and that "fixing" the supposed bug will make things worse for no
> benefit.  I also /do not/ leave bugs unfixed.  Recently I have fixed shallow
> copy for contexts, objects-as-methods, locales on linux and many more.  So
> it is unfair to accuse me of not fixing bugs, and a little intellectually
> lazy of you in this case not to understand the issue that is behind my
> saying we should not "fix" this.  Pl;ease see Andreas' message and my reply
> to it.
>
> OK point taken. Now this is my feedback and feeling.
> I read the explanation on the mail archive and I'm in favor of having a new
> format. When do you expect that?
>

I don't know exactly.  It depends on how much time I have to spend on Cog at
Cadence.  I think there's a good chance of having it done this year.


> Then how much speed does it give you?
>

Difficult to say.  My estimate is a factor of two, based on the comparison
between VisualWorks and Cog since the new object format and GC should be as
good as or slightly better than VisualWorks and from the computer language
shootout VW looks to be about twice as fast as current Cog.


>
> Stef
>
>
> > best,
> > Eliot
> >
> > At least to me the messages is that you are not really interested in
> that. I can understand that you are busy
> > but there is nothing like little issues: because little issues make hard
> stupid people to move and since
> > stupid people are the masses then this means that nothing move. This is
> ok too. but I wanted
> > to let you know the message we receive.
> > I should say that I'm really concerned about the truck factor around Cog.
> If you go to work on something else
> > what will happen. And imagine that nothing improves except speed for a
> couple of years and nothing
> > has the knowledge to understand the system and you leave then we would
> have lost of couple of year
> > making sure that the system is slowly improving and not only from the
> speed perspective.
> >
> > Now about uncompacting classes
> >
> >        - I know that making classes uncompact was working when benjamin
> was working on hazelnut
> >        because he used that to simplify his approach.
> >        Now this is not working anymore so instead of working on the
> bootstrap we will have to understand
> >        what is wrong and turn around.
> >
> >        - Second if simple stuff do not work or cannot even be changed how
> can we think about
> >        bigger changes.
> >
> >        - Third we need a flexible system for making experiments. If we
> remove that from the system then
> >        we should all better go and do ruby or python. May be at the end
> this what we should do.
> >
> >        - Camillo started to work on immutable objects and we check and we
> have 13 compact classes but 5 bits
> >        so it may make sense to keep 4 bits for compact classes and 2 bits
> for experiments (which are really
> >        important to us. it would mean 3 bits since immutability is
> important and we would like to have it).
> >        Then this means that we can live happily waiting for a new object
> format.
> >
> >
> > Stef
> >
> > > >
> > > > and your point would be?
> > > >
> > > it needs to be fixed.
> > >
> > > No.  It does /not/ need to be fixed.  As I said earlier it is *absurd*
> to throw away performance for the ability to change certain classes to
> become uncompact.
> > >
> > > Because if we can't do:
> > >
> > > Smalltalk compactClassesArray do: [:each | each ifNotNil: [each
> > > becomeUncompact]].
> > >
> > > then we cant:
> > >
> > > VM getRidOfCompactClassesNotion
> > >
> > > :)
> > >
> > > That will be done by producing a new GC and a new image format, not by
> tinkering with compact classes in the current GC.  Right?
> > >
> > > > On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> > > >>
> > > >> Hi, i tried to do a simple:
> > > >>
> > > >> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each
> > > >> becomeUncompact]]
> > > >>
> > > >> and it crashing the image.
> > > >> I tried to do this for individual classes.
> > > >>
> > > >>
> > > >> CompiledMethod, ByteString, BlockClosure, BlockContext ,
> > > >>  seems working ok.
> > > >>
> > > >> MethodContext, LargePositiveInteger, LargeNegativeInteger, Float
> > > >> crashes the image.
> > > >>
> > > >> i also tried following:
> > > >>
> > > >> [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each
> > > >> becomeUncompact]]
> > > >> ] forkAt: Processor highestPriority
> > > >>
> > > >> but it didn't helped much.
> > > >>
> > > >> Also, i saved image after couple successfull #becomeUncompact
> steps..
> > > >> and now VM cannot open image, most probably
> > > >> because it fails on 'assumptions check' defined in
> #checkAssumedCompactClasses
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Igor Stasenko AKA sig.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Igor Stasenko AKA sig.
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110508/54202904/attachment-0001.htm


More information about the Vm-dev mailing list