Why the context become a root

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

Why the context become a root

Mathieu SUEN
 
Hi,

Inside Interpreter>>commonReturn the sender context is store inside  
the root table:

commonReturn
        ...

        activeContext := thisCntx.
        (thisCntx < youngStart) ifTrue: [ self beRootIfOld: thisCntx ].
        ...

I am asking why because it is not necessary that the sender context  
will contain young object?


        Mth



Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

Andreas.Raab
 
Because stores into the active context are unguarded (see push bytecodes
etc).

Cheers,
  - Andreas

Mathieu Suen wrote:

>
> Hi,
>
> Inside Interpreter>>commonReturn the sender context is store inside the
> root table:
>
> commonReturn
>     ...
>
>     activeContext := thisCntx.
>     (thisCntx < youngStart) ifTrue: [ self beRootIfOld: thisCntx ].
>     ...
>
> I am asking why because it is not necessary that the sender context will
> contain young object?
>
>
>     Mth
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

Mathieu SUEN
 
Ok so IIRC adding object into the root table that do not contain young  
object do not bug the system.
but every object that contain young object should be inside this table  
otherwise the gc crash?

Next question is where do the root table is update to remove the  
object that dose not contain young one?
I suppose when a full gc is trigger but is there any other moment?

Thanks

On Nov 19, 2007, at 3:47 PM, Andreas Raab wrote:

> Because stores into the active context are unguarded (see push  
> bytecodes etc).
>
> Cheers,
> - Andreas
>
> Mathieu Suen wrote:
>> Hi,
>> Inside Interpreter>>commonReturn the sender context is store inside  
>> the root table:
>> commonReturn
>>    ...
>>    activeContext := thisCntx.
>>    (thisCntx < youngStart) ifTrue: [ self beRootIfOld: thisCntx ].
>>    ...
>> I am asking why because it is not necessary that the sender context  
>> will contain young object?
>>    Mth

        Mth



Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

timrowledge
 

On 19-Nov-07, at 10:23 AM, Mathieu Suen wrote:

> Ok so IIRC adding object into the root table that do not contain  
> young object do not bug the system.
True - we hope!
>
> but every object that contain young object should be inside this  
> table otherwise the gc crash?
Not quite - *old* objects that probably contain young objects need to  
be in the list, which the beRootIfOld: code should hopefully make  
clear. Young objects don't need to be in the root table because they  
get scanned anyway.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Pak Protectors does it take to change a lightbulb?" "Only  
one, but the lightbulb has to smell right."


Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

Mathieu SUEN
 
Yes of course. Thanks for the precision
So all old object that point to a young object should be in the root  
table.
If one of the old object pointing to the young space aren't in the  
root table the vm will probably soon crash. Is it true?

On Nov 19, 2007, at 7:34 PM, tim Rowledge wrote:

>
> On 19-Nov-07, at 10:23 AM, Mathieu Suen wrote:
>
>> Ok so IIRC adding object into the root table that do not contain  
>> young object do not bug the system.
> True - we hope!
>>
>> but every object that contain young object should be inside this  
>> table otherwise the gc crash?
> Not quite - *old* objects that probably contain young objects need  
> to be in the list, which the beRootIfOld: code should hopefully make  
> clear. Young objects don't need to be in the root table because they  
> get scanned anyway.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "How many Pak Protectors does it take to change a lightbulb?" "Only  
> one, but the lightbulb has to smell right."
>
>

        Mth



Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

Andreas.Raab
In reply to this post by Mathieu SUEN
 
Mathieu Suen wrote:
> Ok so IIRC adding object into the root table that do not contain young
> object do not bug the system.

Yes.

> but every object that contain young object should be inside this table
> otherwise the gc crash?

Yes.

> Next question is where do the root table is update to remove the object
> that dose not contain young one?

It's expensive. For every store into the old object you'd have to check
whether it is still a root (which is a linear scan over the object
itself so if it is large it'll be very slow).
> I suppose when a full gc is trigger but is there any other moment?

Yes. When tenuring, the roots table is cleared. A couple of days ago I
toyed with a variant of the collector which used generation aging (e.g.,
tenures objects after it survived so many GCs) and the main task was
deciding whether tenuring should make all tenured objects root or if it
should actually scan them (I think it needs to).

What are you working on?

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

johnmci
 

On Nov 19, 2007, at 3:32 PM, Andreas Raab wrote:

> Mathieu Suen wrote:
>> Ok so IIRC adding object into the root table that do not contain  
>> young object do not bug the system.
>
> Yes.
>
>> but every object that contain young object should be inside this  
>> table otherwise the gc crash?
>
> Yes.
>
>> Next question is where do the root table is update to remove the  
>> object that dose not contain young one?
>
> It's expensive. For every store into the old object you'd have to  
> check whether it is still a root (which is a linear scan over the  
> object itself so if it is large it'll be very slow).

VW will stick the object and the slot into a structure.  This leads to  
the root table dynamically growing based on what is going on. The  
downsize for years was you could  make
the VM crash by causing this root table to grow too fast before some  
other task could do a full GC and tenure the problem objects. I  
understand this issue has been fixed/ or worked around
in current versions of VW. This of course make Squeak slower if you  
stick a large collection object into the root table.   A fix for this  
is to use a dynamic memory policy which considers root table size  
versus scans/etc then invokes a tenure.   In some Squeak code you  
might also find the workaround of allocating a large collection then  
doing a full GC to avoid the excessive root table scan.

>
>> I suppose when a full gc is trigger but is there any other moment?
>
> Yes. When tenuring, the roots table is cleared. A couple of days ago  
> I toyed with a variant of the collector which used generation aging  
> (e.g., tenures objects after it survived so many GCs) and the main  
> task was deciding whether tenuring should make all tenured objects  
> root or if it should actually scan them (I think it needs to).

Didn't early tek system use this, they had 7 generations of old  
space....


>
>
> What are you working on?
>
> Cheers,
>  - Andreas

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================


Reply | Threaded
Open this post in threaded view
|

Re: Why the context become a root

Mathieu SUEN
In reply to this post by Andreas.Raab
 
On Nov 20, 2007, at 12:32 AM, Andreas Raab wrote:

> Mathieu Suen wrote:
>> Ok so IIRC adding object into the root table that do not contain  
>> young object do not bug the system.
>
> Yes.
>
>> but every object that contain young object should be inside this  
>> table otherwise the gc crash?
>
> Yes.
>
>> Next question is where do the root table is update to remove the  
>> object that dose not contain young one?
>
> It's expensive. For every store into the old object you'd have to  
> check whether it is still a root (which is a linear scan over the  
> object itself so if it is large it'll be very slow).
>> I suppose when a full gc is trigger but is there any other moment?
>
> Yes. When tenuring, the roots table is cleared. A couple of days ago  
> I toyed with a variant of the collector which used generation aging  
> (e.g., tenures objects after it survived so many GCs) and the main  
> task was deciding whether tenuring should make all tenured objects  
> root or if it should actually scan them (I think it needs to).
>
> What are you working on?

Nothing special I am just curious and want to learn more about VM stuff.

Thanks
>
>
> Cheers,
>  - Andreas

        Mth