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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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?

AFAIK in the context of generational GC, when a write-barrier records
a mutation in the old/tenured object, different GCs make different
choices w.r.t what is recorded in the "remembered set": the set may
record the new target of the pointer that's assigned (assuming it's
a pointer), or it record the address of the field that's mutated, or it
can record the actual object that's mutated, or it records a "card"
(i.e. a somewhat arbitrary memory region that contains the field,
usually sized and aligned on a power of 2), ...

So IMO what you describe still sits comfortably within the scope of
"remembered set".

> 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.

Generational GCs don't have "a way of detecting when we would want to do
[a major GC] automatically" either.  They just use heuristics.

Regarding "quick hack", I think the main issue is the write barrier.


        Stefan