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

[Eliot Miranda]

On Wed, Nov 30, 2011 at 7:39 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

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

Belay that.  It doesn't fly.  Bitmap is at index 16, not 15.  So close.  Ah
well...  Mariano, you could perhaps make it an option.


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


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