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