[gclist] reference counting

[Jeff Sturm]

"Boehm, Hans" wrote:
> If I understand it correctly, this is different from a cache that keeps
> multiple valid bits per line.  But it should help with our collector.  At
> least in some simple benchmarks a large fraction of the cache misses on
> write occur when an entire page is being written.  Thus it should be safe to
> ignore the previous contents of the page, and hence cache line.

True.  The EV6 has one valid bit per cache block.  I didn't realize at
first you were talking about partial cache lines.

In most of my applications I seldom allocate objects 32 bytes or
smaller, and a minimum cache granularity of 64 bytes seems just about
right.  So although I'm not very interested in subblocking, I'd like to
see what effect I can get with write-allocate.

Could it be that subblocking is seldom implemented because it is too
little benefit for too much added complexity?  I'm certainly no hardware
expert either, but considering the Alpha with a 256-bit path to main
memory, only two memory accesses are needed to fill a cache block, so
the only improvement would be perhaps splitting the block in half.

> I'm not sure whether this is usable with a compacting/copying collector that
> uses a pointer increment allocator.  You have to be more careful, since at
> the time of allocation, the newly allocated object may share a cache line
> with a previously allocated object that has been evicted from the cache.

Good point.  I would think there would also be a benefit when writing
to-space however.

> (Based on some Linux/alpha kernel discussion I found with a quick search,
> this seems a little tricky to use profitably.  Hopefully the instruction is
> a cheap no-op on older processors?  That's a serious issue with the
> multitude of X86 prefetch instructions, some of which trap on some
> processors.)

A bug in GNU binutils caused some of the difficulty.  The WH64
instruction does not trap on a pca56, but I don't have anything older...

Jeff