Re: Opportunistic GC

[Pip Cet]

On Mon, Mar 8, 2021 at 6:06 PM martin rudalics <rudalics@gmx.at> wrote:
>  > 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 ...

You're worried about this patch making it less likely someone will
actually improve the garbage collector? So am I, actually...

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

The space might be counted towards quota limits, but it won't actually
be backed by real memory until it's used. Yes, when the child
terminates, the memory will be freed.

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

Okay, I think I understand now. You're absolutely correct, that's
something the simplistic (but fast) kernel copy-on-write machinery
cannot handle.

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

Ah, but let me try to turn around that argument: if you wanted to
collect such data, my fork-to-GC proposal would be precisely how I'd
do it :-)

Pip