[gclist] reference counting

Boehm, Hans hans_boehm@hp.com
Thu, 14 Sep 2000 10:00:00 -0700

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.

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.
You'd presumably have to issue the WH64 instructions ahead of time.  Has
anyone with access to a new Alpha tried this?

(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


> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm1@home.com]
> Alpha appears to have some support for write-allocate.  The WH64
> instruction specifies that a 64-byte cache line containing a given
> address may be overlaid with unspecified data.  Cache 
> coherency is still
> required for multiprocessors, so I assume WH64 has no effect on
> addresses that are already resident in any cache.  A related
> instruction, ECB, allows early eviction of cache lines.  Perhaps these
> two could benefit a tracing collector?  I haven't 
> experimented much with
> them yet.
> -Jeff