[cap-talk] small notes re: waterken

[Dan Bornstein]

On Mar 5, 2011 9:18 AM, "Sandro Magi" <naasking at higherlogics.com> wrote:
> On 2011-03-04 9:41 PM, Dan Bornstein wrote:
> > Also, in a multi-core world, concurrent gc is one way to get at least a
> > bit more parallel execution out of an app "for free:" Looking at the app
> > (mutator) threads, the barrier overhead imposed by concurrent gc (e.g.
> > write barrier prior to each salient heap update) can reasonably be
> > expected to be much less costly than the refcount accounting overhead
> > imposed by a refcount-based heap.
>
> Perhaps of naive ref-counting implementations. See Bacon and Petrank's
> on-the-fly ref-counting GC. Increment/decrement elision techniques
> significantly improve performance, and deferred ref-counting schemes
> scale fairly well in concurrent scenarios.

I wasn't previously aware of that work. Thanks!

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.

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.

My high-level take is that the paper shows there is still plenty of room for
gc innovation, not that one technique is objectively superior.

-dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20110305/484f4e8d/attachment.html