Fwd: Closure update from eliot

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Closure update from eliot

Stéphane Ducasse


Begin forwarded message:

> From: John M McIntosh <[hidden email]>
> Date: May 1, 2009 7:41:58 PM CEDT
> To: Stéphane Ducasse <[hidden email]>
> Cc: Eliot Miranda <[hidden email]>
> Subject: Re: [Pharo-project] Closure update from eliot
> Reply-To: [hidden email]
>
> Ok to answer the question, when we need to find the class of an  
> object, we invoke either fetchClassOf: or fetchClassOfNonInt:
> now if the class is compact as per the oops header bits we use more  
> bits in the oops header to pull the class oops from the compact array
> using the compact class index value. Otherwise the oops of the class  
> is in the header, which requires more storage for the oops header
>
> When we make the class as compact then it's stuff into the compact  
> array and allInstances of the old class converted.
>
>
> Lastly, well I'm wondering about the impact on image segments.
>
> The comment in becomeCompact: says...
>
> "Here are the restrictions on compact classes in order for export  
> segments to work:  A compact class index may not be reused.  If a  
> class was compact in a release of Squeak, no other class may use  
> that index.  The class might not be compact later, and there should  
> be nil in its place in the array."
>
> But I wonder if
> remapCompactClasses:refStrm:
>
> ensures accidents don't happen, however let's see if Eliot has cross-
> checked this issue, no doubt the the comment is dated...
>
>
> Also
> PseudoContext(class)>>initialize
> seems rather obsolete then?
>
>
> On 1-May-09, at 3:10 AM, Stéphane Ducasse wrote:
>
>> I have a stupid question about this one.
>> Does it mean that we should fix that at the level of the vm since  
>> compactClassesArray is a primitive
>> and recreateSpecialObjectsArray used it.
>>
>> stef
>>
>> Begin forwarded message:
>>
>>> From: Stéphane Ducasse <[hidden email]>
>>> Date: May 1, 2009 11:55:45 AM CEDT
>>> To: Pharo Development <[hidden email]>
>>> Subject: [Pharo-project] Closure update from eliot
>>> Reply-To: [hidden email]
>>>
>>>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Closure update from eliot

Stéphane Ducasse
now as

        http://code.google.com/p/pharo/issues/detail?id=789
On May 1, 2009, at 9:31 PM, Stéphane Ducasse wrote:

>
>
> Begin forwarded message:
>
>> From: John M McIntosh <[hidden email]>
>> Date: May 1, 2009 7:41:58 PM CEDT
>> To: Stéphane Ducasse <[hidden email]>
>> Cc: Eliot Miranda <[hidden email]>
>> Subject: Re: [Pharo-project] Closure update from eliot
>> Reply-To: [hidden email]
>>
>> Ok to answer the question, when we need to find the class of an
>> object, we invoke either fetchClassOf: or fetchClassOfNonInt:
>> now if the class is compact as per the oops header bits we use more
>> bits in the oops header to pull the class oops from the compact array
>> using the compact class index value. Otherwise the oops of the class
>> is in the header, which requires more storage for the oops header
>>
>> When we make the class as compact then it's stuff into the compact
>> array and allInstances of the old class converted.
>>
>>
>> Lastly, well I'm wondering about the impact on image segments.
>>
>> The comment in becomeCompact: says...
>>
>> "Here are the restrictions on compact classes in order for export
>> segments to work:  A compact class index may not be reused.  If a
>> class was compact in a release of Squeak, no other class may use
>> that index.  The class might not be compact later, and there should
>> be nil in its place in the array."
>>
>> But I wonder if
>> remapCompactClasses:refStrm:
>>
>> ensures accidents don't happen, however let's see if Eliot has cross-
>> checked this issue, no doubt the the comment is dated...
>>
>>
>> Also
>> PseudoContext(class)>>initialize
>> seems rather obsolete then?
>>
>>
>> On 1-May-09, at 3:10 AM, Stéphane Ducasse wrote:
>>
>>> I have a stupid question about this one.
>>> Does it mean that we should fix that at the level of the vm since
>>> compactClassesArray is a primitive
>>> and recreateSpecialObjectsArray used it.
>>>
>>> stef
>>>
>>> Begin forwarded message:
>>>
>>>> From: Stéphane Ducasse <[hidden email]>
>>>> Date: May 1, 2009 11:55:45 AM CEDT
>>>> To: Pharo Development <[hidden email]>
>>>> Subject: [Pharo-project] Closure update from eliot
>>>> Reply-To: [hidden email]
>>>>
>>>>
>>
>> --
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> John M. McIntosh <[hidden email]>   Twitter:
>> squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://
>> www.smalltalkconsulting.com
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project