[cap-talk] small notes re: waterken

[Sandro Magi]

On 2011-03-05 1:53 PM, Dan Bornstein wrote:
> Near as I could tell from a quick skim of the paper
> (<http://www.research.ibm.com/people/d/dfb/papers/Paz05Efficient.pdf>),
> the dedcribed scheme is at best a wash compared to concurrent tracing,
> depending on workload.

Indeed, though the two orders of magnitude lower pause times are a great
selling point. This GC would provide hard real-time bounds for programs
executing in CPS form, though it's the sliding views and not the
ref-counting that matters here. Petrank's mark-sweep based on sliding
views has essentially the same advantages.

> It also doesn't seem to guarantee collection being particularly
> prompter, since there's always the risk of having to wait for the cycle
> collector before seeing memory/resources get reclaimed. I thought the
> point of advocating for refcounting in the context of RAII was
> specifically about the guarantees, so it's not clear to me what the real
> advantage of "on-the-fly" is, in this case.

Yes, prompt reclamation was not the goal. This sort of GC has three
advantages that I can see:

1. More efficient in tighter heaps (discussed in the paper).
2. Friendlier to virtual memory, unlike tracing. Major collections of
large heaps in tracing GC may involve lots of paging. You can imagine
how a ref-counting scheme with local cycle collection is less likely to
page in objects that are not being operated on.
3. No "stop the world", ie. mutators and collectors are all running
concurrently, resulting in very low latency (~2ms IIRC).

Sandro