On Wed, Nov 30, 2011 at 1:19 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Nov 29, 2011 at 10:27 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Tue, Nov 29, 2011 at 11:54 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Mon, Nov 28, 2011 at 7:25 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Sat, Nov 26, 2011 at 3:02 PM, Chris Muller asqueaker@gmail.comwrote:
Compact classes cannot be made uncompact in a Cog+JIT VM.
Not exactly true. Certain classes cannot be uncompacted. These are as defined by StackInterpreter>>#checkAssumedCompactClasses and the ones that can't be uncompacted are Array LargeNegativeInteger LargePositiveInteger Float MethodContext
There is a performance advantage to being able to identify instances of these classes from the compact class index.
But any other classes should be able to be compacted and uncompacted.
Eliot, should we validate this in image side (#becomeUncompact) ?
I suppose so. The "right" way to do this would be to ask the VM (via a primitive) for the set of assumed compact classes, but that's too much work.
I agree. So I will try to add the validation.
I hope that a new GC/object representation will become available before I would ever think of changing the set of compact classes, so having the method document what the current VM requires is ok.
Eliot, a simple question: In Pharo: Smalltalk compactClassesArray asSet size -> 15 Smalltalk compactClassesArray asSet size -> 13
I would like to have one extra free bit in the object header. I can hack my own VM which uses 4 bits for CompactClasses rather than 5, but do you think we can do this for the official Cog VM as well? this would allow "researched" a much nice infrastructure out of the box. How much work can be such change? is there someone needing 32 compact classes? if I do a SpaceTally new printSpaceAnalysis it looks like if I only need the first 10 classes....
I know in the future you want to change all this thing about compact classes, but if we can have one free bit tomorrow (instead of "in the future"), then this is very very good.
Seems reasonable. What do you think Andreas, David, Esteban, Ian? Shall we make this change?
Thanks in advance,
Can compact classes be made uncompact when running the StackInterpreter VM?
It is exactly the same story. The same classes are assumed to be compact in the StackInterpreter VM as the CoInterpreter VM.
Thanks.
HTH
best, Eliot
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com