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

[Eliot Miranda]

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.

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/20110507/73c1291a/attachment-0001.htm