[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opportunistic GC

From: martin rudalics
Subject: Re: Opportunistic GC
Date: Mon, 8 Mar 2021 12:37:21 +0100

>> And short-lived objects have to
>> wait for the next cycle to get recovered.
> I'm not aware of any GC algorithm that recovers objects allocated
> after the GC cycle started :-)

In the early phase of a collection cycle most objects are unmarked so it
would make sense to give a new object the mark status of the first
object referencing it.  But that's admittedly hard to do with ambiguous

> Mostly that there should not be a doubling of memory usage. With the
> mark bits fixed, memory usage would grow by, at most, 1/64th the heap
> size on 64-bit systems, plus a constant. I think we can live with a
> 1.5% increase in memory usage if we get (effectively) zero-cost (or
> zero latency) GC in exchange. (I'm assuming there'll be an unused CPU
> core, which is usually true for me (unless I'm compiling something)).
> With the mark bits not fixed, memory usage would increase by
> approximately the size of the surviving heap, but not the size of the
> discarded heap pages.

But doesn't that depend on how many writes the Lisp thread performs in
the heap?  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.

> Note that none of this is "real" GC: we still mark and sweep, just in
> a slightly smarter way.

If with "real" you meant "real-time", then it might qualify as such.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]