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
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
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
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; tim@rowledge.org; 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."
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; tim@rowledge.org; 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
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
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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
John M McIntosh -
Mathieu Suen -
tim Rowledge