On 6 May 2011 20:04, Eliot Miranda eliot.miranda@gmail.com wrote:

and your point would be?

it needs to be fixed.

Because if we can't do:

Smalltalk compactClassesArray do: [:each | each ifNotNil: [each becomeUncompact]].

then we cant:

VM getRidOfCompactClassesNotion

:)

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.

On 6 May 2011 21:51, Eliot Miranda eliot.miranda@gmail.com wrote:

On Fri, May 6, 2011 at 12:47 PM, Igor Stasenko siguctua@gmail.com wrote:

...

On 6 May 2011 20:04, Eliot Miranda eliot.miranda@gmail.com wrote:

...

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.

No. its nothing to do with performance. It is about getting rid of them as a concept.

...

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?

yes.. but small steps at a time.

Дорогу одолеет идущий.

(its hard to me to translate this but if translate it literally, it means): 'road' 'overcome' 'walking one'

...

...

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.

On 5/7/2011 2:33, Colin Putney wrote:

On Fri, May 6, 2011 at 5:18 PM, Igor Stasenkosiguctua@gmail.com wrote:

...

No. its nothing to do with performance. It is about getting rid of them as a concept.

Well, if fixing it makes Cog slower, then it *is* about performance.

Just making everything uncompact without changing the image format doesn't really buy us much: it would make Cog slower and the image bigger with no benefit. The benefit comes from having a new image format that is optimized for speed rather than space - getting rid of compact classes would just be a side-effect of the new format.

And interestingly, Eliot's proposal for a new format actually gets rid of the class pointer and makes "everything" a compact class.

Cheers, - Andreas

On Sat, May 7, 2011 at 7:09 AM, Andreas Raab andreas.raab@gmx.de wrote:

And interestingly, Eliot's proposal for a new format actually gets rid of the class pointer and makes "everything" a compact class.

Ooh, I'd like to know more. Is that proposal written up anywhere?

Colin

On 2011-05-07, at 10:33 AM, Andreas Raab andreas.raab@gmx.de wrote:

I don't recall if Eliot has published all the details (we went over it during some lunch break once) but the basic idea is described here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.ht... http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206...

(of course, the compact class index is just an index into a class table)

Ok, I remember that now. I guess I was looking for a higher-level description based on the whys and wherefores. It sounds like the advantage here is space-saving, not speed: surely a class pointer is faster to deal with than a multi-level table lookup. I guess it's necessary because 64-bit pointers take a lot of space if you have one for each object?

Colin

On Mon, May 9, 2011 at 1:52 AM, stephane ducasse <stephane.ducasse@gmail.com

wrote:

Hi andreas

...

I don't recall if Eliot has published all the details (we went over it

during some lunch break once) but the basic idea is described here:

...

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.ht...

...

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206...

I read the second link multiple times but I could not get the following:

"- sending a message to an object. The object's class and the message's selector are quertied for their identity hash. If either object does not have one it is assigned. So the class object is identified from context; it is the class of the receiver."

I could not understand the last sentence from the second link.

This is a mistake on my part. In this scheme it is impossible to have an instance of a class and that class not have an identityHash. I was talking about/getting confused with the standard VisualWorks VM where a class may be assigned an identityHash on send. In the class index scheme classes get assigned identity hashes either in a special version if the identityHash primitive for Behavior (e.g. when one puts a class in an IdentitySet) or when a class is instantiated. So the check for classes having identityHashes (which are also their table indices and hence the class indices of their instances) is on instantiation, not send. Sorry.

"One nice thing I didn't mention is that one can use "class index puns".

There is nothing to prevent the VM from entering a class into the class table more than once. So I entered in WeakArray twice into the class table, and used one as a hidden class index for the pages of the class table itself. When one does WeakArray allInstances, therefore, the class table pages are not found. Further, the finalization machinery can easily identify a class table page, because it has a unique class index, and so the maintennance of the first unused class table slot index is very cheap."

I could not understand the trick of entering the weakarray twice.

So we want to use WeakArray for the class table pages since we don't want to hold onto classes strongly through the class table, only through instances. Bt the class table should remain a hidden object, not visible to the image; it is part of the VM implementation, not an official part of the specialObjectsArray. So e.g. these pages shouldn't turn up in WeakArray allInstances. By using a pun for WeakArray (so that there are two entries in the class table that map to the WeakArray class) and using one of these only for the class table pages then WeakArray allInstances won't include them. I'm not sure this is so important, but it is a way of using the heap for the VM to allocate memory without that memory becomming visible to the image.

is this understandable yet?

best, Eliot

Stef

On Sat, 7 May 2011, Igor Stasenko wrote:

On 6 May 2011 21:51, Eliot Miranda eliot.miranda@gmail.com wrote:

...

On Fri, May 6, 2011 at 12:47 PM, Igor Stasenko siguctua@gmail.com wrote:

...

On 6 May 2011 20:04, Eliot Miranda eliot.miranda@gmail.com wrote:

...

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.

No. its nothing to do with performance. It is about getting rid of them as a concept.

Why? What would be the benefit of keeping the image format, but getting rid of compact classes?

...

...

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?

yes.. but small steps at a time.

It's good to follow this rule in most cases, but this is an exception, because once you change your image to not use the compact object representation, you won't be able to use it with current VMs. This kind of change should be avoided or it must bring real benefits that outweight the cost of incompatibility. At the moment I don't see the benefits other than five new free bits in the object header and a bit simpler code for the VM which is not enough IMHO. On the other hand larger objects will probably result in a slower VM (less objects can be cached, more objects will have to be moved around in the memory hierarchy).

Levente

˙˙˙˙˙˙˙˙˙˙˙˙ ˙˙˙˙˙˙˙˙˙˙˙˙˙˙ ˙˙˙˙˙˙˙˙˙˙˙˙.

(its hard to me to translate this but if translate it literally, it means): 'road' 'overcome' 'walking one'

...

...

...

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.

-- Best regards, Igor Stasenko AKA sig.

On 5/7/2011 9:25, Tobias Pape wrote:

...

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.

When it worked in pre-cog VMs, why should it break in Cog?

Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them.

Cheers, - Andreas

On 7 May 2011 16:15, Andreas Raab andreas.raab@gmx.de wrote:

On 5/7/2011 9:25, Tobias Pape wrote:

...

...

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.

When it worked in pre-cog VMs, why should it break in Cog?

Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code.

Where is the metrics? I need to know what we lose if we do it one or another way.

And since Cog don't allows me to turn compact class back to be normal class (simply crashing), i cannot measure it.

Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff.

In theory. But you have no proof now. Why i should trust you/Eliot/anyone else, without being able to test it?

If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them.

It was not necessary to ban uncompaction. I would ban a creation of new compact classes, but not turning compact one to be uncompact again.

Also, i don't want to do anything with old Interpreter. It makes no sense to see % slowdown in old interpreter and assume you will have same for Cog. It can be completely different. Comparing Interpreter and Cog is like comparing apples and oranges.

I wanted to do a simple experiment: - create an image which has no compact classes - modify cog to not use compact class header

so i can measure pro and cons..

Now , it looks like i cannot do it in simple way, because Cog simply cannot run such image(s), because some code in Cog are nailed down presence of concrete compact classes.

On 7 May 2011 22:38, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

Now , it looks like i cannot do it in simple way, because Cog simply cannot run such image(s), because some code in Cog are nailed down presence of concrete compact classes.

do you know which are the list of classes that Cog expects to be compact? and are there classes that cog expect to be non-compact? which ones?

to get an answer just read the first message of this thread :)

Thanks in advance,

-- Mariano http://marianopeck.wordpress.com

Therefore, some classes

...

...

cannot be made non-compact in Cog, and that is a perfectly good tradeoff.

In theory. But you have no proof now. Why i should trust you/Eliot/anyone else, without being able to test it?

You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't...

Hi andreas

your points are totally valid. Now the point is that it does not look like we are building a community around Cog, more a sect and this is sad - even if eliot is doing his best to answer the stupid questions of people like mariano. I organized the school deep into smalltalk and payed eliot for his talks just to spread the knowledge. For me this is important to discuss and that knowledge is spread on pros and cons. So at least the links you sent were good.

Now personally I do not use Cog yet just to see how far I need to be bound to something complex and understood by two persons. This is my way to manage my own risks in my business. So making pharo fast on the interpreter is a reasonable approach too. I think that our little community should realize that, else one day it can be hurt.

This is sad that we do not succeed to build a set up where the community could pay eliot to work on Cog but this is like that so far. I tried some setup but so far this is not working. Now even if this would be the case, how a set of companies would invest money in something that only one guy or two understand. I think that if we do not minimize the truck factor then we have a high risk profile that investors should be able to understand quite well and run away from us (or they are blind which is better). After we should not cry when "rewrite everything in java" arrives (even if it may be for other less obvious reasons). As an investor of the money for my kids I tend to be much more picky about reality and risks. Having kids is a good way to check reality.

Stef

On 8 May 2011 21:02, Eliot Miranda eliot.miranda@gmail.com wrote:

On Sun, May 8, 2011 at 3:24 AM, stephane ducasse stephane.ducasse@gmail.com wrote:

...

...

Therefore, some classes

...

...

cannot be made non-compact in Cog, and that is a perfectly good tradeoff.

In theory. But you have no proof now. Why i should trust you/Eliot/anyone else, without being able to test it?

You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't...

Hi andreas

your points are totally valid. Now the point is that it does not look like we are building a community around Cog, more a sect and this is sad - even if eliot is doing his best to answer the stupid questions of people like mariano. I organized the school deep into smalltalk and payed eliot for his talks just to spread the knowledge. For me this is important to discuss and that knowledge is spread on pros and cons. So at least the links you sent were good.

Now personally I do not use Cog yet just to see how far I need to be bound to something complex and understood by two persons. This is my way to manage my own risks in my business. So making pharo fast on the interpreter is a reasonable approach too. I think that our little community should realize that, else one day it can be hurt.

How many people really understand the VisualWorks JIT or any other high-performance VM?  In my experience few people have the interest, skills and experience in language design and implementation and low-level computer architecture.  There are relatively few really good VM engineers compared to the number of really good high-level object-oriented programmers.  That matches perfectly with the far smaller number of VMs than interesting object-oriented programs.  A VM, like any other piece of core infrastructure has a very high rate of use.  I don't see anything unusual, surprising or worrying about this.  How is it that different from Ian, Andreas, John and David as the keepers of the Interpreter before Cog? Further Nicholas demonstrated this week that with a little intellectual effort someone really good can come to understand Cog and make a contribution quite quickly.  Instead of all this FUD about there not being a community around Cog why not try and play with it, as Nicholas has successfully, and we can start building the community.  I'm not going to respond well to bullying tactics.  I respond well to real collaboration (thanks Marcus, Nicholas, Levente, Andreas, Igor, Mariano and all who have found and reported bugs).

...

This is sad that we do not succeed to build a set up where the community could pay eliot to work on Cog but this is like that so far. I tried some setup but so far this is not working. Now even if this would be the case, how a set of companies would invest money  in something that only one guy or two understand. I think that if we do not minimize the truck factor then we have a high risk profile that investors should be able to understand quite well and run away from us (or they are blind which is better). After we should not cry when "rewrite everything in java" arrives (even if it may be for other less obvious reasons). As an investor of the money for my kids I tend to be much more picky about reality and risks. Having kids is a good way to check reality.

Why express such FUD?  I am happily at Cadence again and will have the freedom to spend significant time on Cog (with Newspeak also).  And there are a few other potential places I could end up working on Cog.  Meanwhile people like Nicholas will gain a better understanding of Cog, people like Mariano will produce ever more comprehensible documentation, people like Marcus will evolve it in really interesting performance directions and people like Igor will evolve its basic architecture away from a monolithic simulated-in-Smalltalk system to a true live bootstrap.  Others will work on the FFI and Cog will evolve into a key component of a powerful open-source Smalltalk platform.  The community /is/ building.  Relax.

Be cool, Stephane. JIT is more complex, sure thing. Entry point is high. Sure thing. But the road overcomes a walking one. So little steps at a time. It is just a smalltalk code, after all. Yes, it is slang, and because its a slang, its even more 'stupidified' code than usual smalltalk. Yes, its more tedious to code in 'slang mode' , because you need to make sure it will be translated, but it is still better than writing everything in C.

On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda eliot.miranda@gmail.comwrote:

On Sat, May 7, 2011 at 7:15 AM, Andreas Raab andreas.raab@gmx.de wrote:

...

On 5/7/2011 9:25, Tobias Pape wrote:

...

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.

When it worked in pre-cog VMs, why should it break in Cog?

Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them.

Thank you Andreas. Exactly. Determining the class of an instance of a compact class is faster than determining the class of an instance of a non-compact class if the compact class index is known.

This is what I don't understand. Even if the compact class index is known, why is it that faster than non-compact? because in non-compact you need to fetch the class pointer from the object header? But... regardless that the compact class index is know, you also have to get the index (those 5 bits) from the OH. So I don't see why there is so much difference in performance.

So in asking "is the receiver a LargeInteger" or "is the receiver a Float" in the VM is significantly faster if the compact class index is a constant.

You mean that to answer "is the receiver a LargeInteger" you don't need to fetch the class of the receiver and then do a speObj: comparison, but instead get the compact class index from the OH and compare to a known value ???

If we introduce the in-practice unused facility to allow all classes to become uncompact we lose this performance advantage. I do not see the point of losing performance to support unused or useless functionality.

...

Cheers,

• Andreas

On 8 May 2011 14:39, Mariano Martinez Peck marianopeck@gmail.com wrote:

On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

On Sat, May 7, 2011 at 7:15 AM, Andreas Raab andreas.raab@gmx.de wrote:

...

On 5/7/2011 9:25, Tobias Pape wrote:

...

...

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.

When it worked in pre-cog VMs, why should it break in Cog?

Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them.

Thank you Andreas.  Exactly.  Determining the class of an instance of a compact class is faster than determining the class of an instance of a non-compact class if the compact class index is known.

This is what I don't understand. Even if the compact class index is known, why is it that faster than non-compact?   because in non-compact you need to fetch the class pointer from the object header? But... regardless that the compact class index is know, you also have to get the index (those 5 bits) from the OH.  So I don't see why there is so much difference in performance.

to prove or disprove that you have to check how fast VM with and without compact classes.

...

So in asking "is the receiver a LargeInteger" or "is the receiver a Float" in the VM is significantly faster if the compact class index is a constant.

You mean that to answer "is the receiver a LargeInteger"   you don't need to fetch the class of the receiver and then do a speObj:  comparison, but instead get the compact class index from the OH and compare to a known value ???

yes, it is faster to compare compact class index in OH with constant, instead of fetching the class of object and comparing it to class which held in special objects array at certain index.

In fact, i am used the same trick in NativeBoost callout generation. To test if passed argument is instance of float, its just checks the object's header and its compact class index value. This is trivial optimization , which lies on surface.

But then, it is dynamically generated code, which i can discard at any moment. And if Float will be non-compact next time, it will generate different code, according to situation.

This means, that it is possible to keep flexibility without sacrificing speed. And that's what i trying to argue.

...

If we introduce the in-practice unused facility to allow all classes to become uncompact we lose this performance advantage.  I do not see the point of losing performance to support unused or useless functionality.

Me neither.

-- Mariano http://marianopeck.wordpress.com

On 5/8/2011 8:38, Tobias Pape wrote:

Am 2011-05-07 um 16:15 schrieb Andreas Raab:

...

On 5/7/2011 9:25, Tobias Pape wrote:

...

...

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.

When it worked in pre-cog VMs, why should it break in Cog?

Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you)

Only two versions of object headers. not three.

But why? If your argument is that two object headers make the VM simpler, then my response is: Go use the interpreter. It's *much* simpler than the JIT and if your goal is conceptual simplicity, then the JIT clearly isn't for you. A JIT by its very nature must make some tradeoffs in order to perform better and if you don't like the tradeoffs you'll have difficulties to actually get the performance you're looking for.

Cheers, - Andreas

...

then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them.

Cheers,

• Andreas

So Long, -Tobias

Hi Stephane,

On Sat, May 7, 2011 at 1:35 AM, stephane ducasse <stephane.ducasse@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@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.

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

Hi Stephane,

...

On Sat, May 7, 2011 at 1:35 AM, stephane ducasse <

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