[Vm-dev] Re: [squeak-dev] uncompacting classes

Eliot Miranda eliot.miranda at gmail.com
Thu Dec 1 03:39:05 UTC 2011


On Wed, Nov 30, 2011 at 1:19 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>
> On Tue, Nov 29, 2011 at 10:27 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>>
>>
>> On Tue, Nov 29, 2011 at 11:54 AM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Mon, Nov 28, 2011 at 7:25 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Sat, Nov 26, 2011 at 3:02 PM, Chris Muller <asqueaker at gmail.com>wrote:
>>>>
>>>>> 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
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111130/77e59bd0/attachment.htm


More information about the Vm-dev mailing list