[gclist] reference counting
Fri, 15 Sep 2000 00:11:55 -0400
"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
> (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
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...