Design of persistent tag cache

[Greg Ward]

On Sun, Jul 5, 2009 at 5:59 PM, Brendan Cully<brendan at kublai.com> wrote:
> I haven't been paying too much attention to this thread I'm afraid,
> but it sounds like you could just explicitly update the cache during
> strip, rather than on some subsequent generic operation? It should be
> possible to calculate the missing info efficiently when you know
> what's being stripped, and the expense of updating the cache should be
> dwarfed by the cost of strip, which isn't a fast-path operation
> anyway.

Not with "cache design #1" as suggested by Matt and implemented by me.
 That version stores the synthesis of tag info from across all heads,
so it doesn't know which info to throw away on a strip.  Doesn't
matter if you do it early, at strip time, or late, when validating the
cache and realizing a head has been removed (for whatever reason).

My proposed "cache design #2" would enable that sort of intervention.
Hmmm.  I'll have to think about it to see if it's worth it.  I'm not
sure it is.  Also, my first attempt at tag caching (back in May) tried
to detect *all* cache invalidations early, and Matt's "design #1" was
a pretty compelling argument in favour of late detection.  (Better
performance, less invasive code, and less chance of getting it wrong.)
 A hybrid late/early model feels awkward.

Greg