Stupid pdump+GC suggestion
Jan Vroonhof writes:
Although I like a hashing GC, I agree it may be too much to change at
this moment.
I am I correct in thinking that pre-hash we have
1. Read-only lisp objects
2. A GC collecter that works like this
a. Walk over all lisp objects, clearing the mark bit.
b. starting at the roots walk the graph of reference as follows
- Mark bit was set.
no action
- Mark bit was not set
set mark bit
recurse over children
c. Walk over all objects freeing those that have not been marked.
This is not correct. It should be
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.
b. Walk over all objects freeing those that have not been
marked, and unmarking everything else.
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.
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 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.