New subject: Stupid pdump+GC suggestion

Thursday, 14 October 1999

        Kyle Jones <kyle_jones(a)wonderworks.com&gt; writes:

...
     2. A GC that works like this
        a. start at the roots of accessibility (the obarrary, the
 	  GCPRO list, the staticpro list, catch lists, etc.) and mark 
 	  all referenced objects and objects that those objects
 	  reference, recursively. 
But surely you must stop recursing into already marked objects (to
avoid loops)? I now checked and it does indeed do that. In fact it
already bails out earlier if the object is read-only.

...
        b. Walk over all objects freeing those that have not been
 	  marked, and unmarking everything else. 
Yes but this is conceptually the same as my phases "a" and "c" just
merged into one for efficiency.

...
  > Won't we get something extremely purespace-like, by
  >   i)  pdumped object are read-only _and have the mark bit set_
  >   ii) in phase a and c walk only over the non-pdumped objects?

 Given the revised GC description, obviously this won't work. 
Sorry but it is not obvious to me at all. Just replace "all" in b. by
"all non-pdumped".

...
 However, the current non-hashed GC has a pure bit in the
 lrecord header.  This can be used to make GC not mark or
 otherwise molest dumped objects that should be considered
 read-only. 
In fact mark_object already works that way.

...
 In the dumper I was considering, there would
 also have been a `held' bit that would be set for read-write
 objects referenced by a read-only object.  Objects with the
 'held' bit would not be reclaimed by the GC. 
Do you think there would be enough such objects around that this is
worth it? (The problem is that you need to treat these held objects as 
additional roots).

Jan

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Re: Stupid pdump+GC suggestion