Re: Merging scratch/no-purespace to remove unexec and purespace

[Pip Cet]

"Stefan Monnier" <monnier@iro.umontreal.ca> writes:

>> My idea is this: we add an extra mark bit area to the pdumper file for
>> objects which we know to be "tenured": i.e. objects that we'll treat as
>> immortal, but for which we also know that all referenced objects will
>> also be "tenured", or static.
>
> IIUC this sounds like a kind of generational GC, except that promotion
> to the "tenured" set is made somewhat visible instead of being 100% internal.

Kind of a very special case of it, but there's no major GC and we accept
that objects in the "old" generation are simply immortal.  I think it's
easier to get to the concept by starting from "here's a quick hack"
rather than "start with generational GC, then remove bits from it until
all that's left is a quick hack".

I was intending for the promotion to be invisible to "normal" Lisp
users, though.  Sorry if that didn't become clear.

>> If we write to such an object, we clear the bit, and put it on a special
>> set to maintain its tenure (it'd be nicer to simply set another bit, but
>> non-MPS pdumper cannot do so).  This should happen rarely, but it's
>> better than the current CHECK_IMPURE thing.
>
> If my understanding above is correct, then the
> `CHECK_IMPURE/check_writable` is what we usually call "write barrier",

Yes. I was trying to avoid the term because there are other uses for
check_writable than clearing a write barrier, particularly if we pair
each call to check_writable with one to
no_longer_care_whether_the_object_is_writable.

> and the "special set" above is what we usually call the "remembered set".

TBH, I'm not entirely sure about that one, and I see I misspoke there;
while the object remains immortal (and thus "tenured"), it's no longer
considered skippable; in effect, the object combines the disadvantages
of being young and being old, permanently, rather than clearly being one
of the two.  I guess you could say we turn it into an additional root?

It becomes much closer to generational GC if you reintroduce "major" GCs
which would recalculate the tenure of all objects, but that's where we
hit the limits of "quick hack" territory, and I don't see a way of
detecting when we would want to do so automatically.

Anyway, leaving those very general questions aside, char table GC is
inefficient and fixing it will speed up the first few GCs considerably,
and we can do so without making anything "pure".

Pip