Re: Opportunistic GC

[martin rudalics]

> I don't think it's going to matter in practice, though. GC, after all,
> does not take that long,

.. as long as we do not increase the heap size with the excuse that GC
is now no more intrusive anyway ...

> and the retained working set of most Lisp
> programs is small, memory is cheap, and it is a factor of two in the
> absolute worst conceivable case.

We don't have to reserve that space and closing the fork automatically
returns it to the OS?  I have no idea how copy-on-write is implemented.

>> Each such write causes its associated page getting written
>> out to avoid that an old link gets lost.  And if the action was to drop
>> an old link, writing the page out doesn't even make sense.
>
> I'm not sure what you mean by "drop an old link".

Setting a car or cdr to nil (as opposed to setting a car or cdr to some
other cons cell).  In this case, the copy on write will trigger a fault
on that object's page to make sure that the previous reference gets
traced by the collector.  Usually, concurrent collectors do not care.

> No, I meant "real" as opposed to mark-and-sweep style algorithms.
> Generational would have been a better (but possibly slightly
> narrower?) term.

So you mean mark-and-sweep as opposed to copying.  In principle, a
generational collector could be mark-and-sweep too.  Just that its
paging behavior would be probably disastrous over time.

We never collected any evidence on how long Elisp objects live.  So it's
not clear how much we could gain from promoting long-lived objects.

martin