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

[stephane ducasse]

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?
Then how much speed does it give you? 

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.
> >
> 
>