[gclist] reference counting

[Mark Hamburg]

>Date: Tue, 5 Sep 2000 07:20:05 -0400
>From: Greg Morrisett <jgm@cs.cornell.edu>
>Subject: [gclist] reference counting
>
>(3) It's also not clear to me that pointer-bump allocation is
>as huge a win as people think.  A good non-compacting organization
>(as in the BDW collector) can allocate objects almost as fast.
>They have the added advantage of not requiring twice the space
>as a copying collector and thus can do roughly half as many
>collections.  Indeed, Fred Smith and I found that the "wins"
>of compaction were blown away by the space overheads of accuracy
>(needed header words on objects) and copying.  This was in the
>context of a comparison we did for our ML-to-C compiler using
>a mostly copying collector (with fast, inlined allocation
>routines) versus the BDW conservative collector.

Pointer bump allocation also potentially has page fault issues that don't
get accounted for. A storage management system that reuses the same memory
repeatedly won't suffer as much page fault vagrancy. This is why stack
allocation is generally to be preferred to pointer bump allocation for
activation records provided that issues like closures and continuations
don't interfere.

Mark

P.S. I worry that I'm going to come off as a big defender of reference
counting. I'm not. I know it's got a lot of flaws. It's just that I think
that some of the messages on this list fail to recognize why it is so
widely used. My point in this message wasn't that pointer bump is
necessarily bad -- it may well do better on locality than free-list
allocation -- but that it's virtues get overstated on occasion.