Read an evicting cache as an evicting cache, for the caches an app really has

[pyricau]

The explorer's CACHE strength exists so that an object only a cache holds reads as
what it is: bytes that go away on their own. Until now it knew about one cache, Coil 3's,
because Coil wraps each cached value in a class of its own and naming that class and its
field is the whole of it.

The caches an app is more likely to have don't wrap anything. This adds them, in two
steps, both measured against dumps that have them.

Glide's pools

LruBitmapPool keeps bitmaps to hand out again rather than allocate, LruArrayPool keeps
the arrays a decode reads through, and both drop everything on onTrimMemory. A pooled
object is in memory because it is free, so reading those bytes as strongly held says an
app is using memory it has already finished with.

Both keep what they hold in one GroupedLinkedMap, so one entry covers the two of them.
On an API 36 dump of an app with two bitmaps pooled and four decode buffers: 5.1 MB and
15 objects move out of STRONG and read as CACHE, still dominated by the pool, since
nothing else holds a free object.

The caches with a plain map: android.util.LruCache, Picasso's, Glide's

These keep what they cache in a java.util.HashMap, and the only thing between the cache
and the value is a HashMap$Node every map of the heap dump shares. Weakening that node's
value field by class name would weaken every map there is; weakening the cache's map
field would take the table, the entries and the keys down with it, and a cache's own
bookkeeping belongs where it is, strongly held and attributed to the cache.

So which entries belong to a cache is read off the heap dump instead. CachedMapValues
reads the map of each cache and remembers which node holds which value; that one reference
then reads as CACHE and everything above it stays STRONG. It costs one pass over the
classes and one over the instances — 30 to 45 ms on large-dump.hprof, the biggest dump
in the repo — and is built on first use, as a whole map assigned at once, like the
explorer's other indexes.

What it does, measured:

• large-dump.hprof: 3.9 MB — the 760×1262 bitmap and a 126×126 one, with their
  pixels — move out of STRONG and read as the Picasso cache they sit in. That is 13% of
  everything that dump held strongly, and it used to sit at the top of the tree with
  nothing to blame.
• android.util.LruCache moves nothing on either dump, and is in the list for the app's own
  caches rather than for a measurement of its own: all fourteen instances of it in large-dump.hprof
  are the framework's or a library's — nine SQLite prepared statement caches, a job cache, a typeface
  cache, two empty — and hold no image.
• An API 36 dump of an app loading through Glide: the three images nothing is
  displaying any more read as its LruResourceCache, while the three a view shows stay
  STRONG under the view. Which is the rule doing its job in both directions — a cache
  only holds what nothing else does.

A map's entries, in shark

Reading a cache's map started out as a walk of its own here — a field called table, next
down each bucket, value off every node, matched by name against the whole instance because
which class declares them differs between runtimes. That is a walk Shark already has, written
a second time and against names it knows better.

So this adds the half of Shark's own walk that has no opinion. OpenJdkInstanceRefReaders and
ApacheHarmonyInstanceRefReaders read a map into references straight from the map to each key
and value, the HashMap$Node between them left out because a leak trace shouldn't name it —
which leaves nothing to say about the node, and holding its value weakly is exactly what this
PR needs to say. The new shark.MapEntryReader asks those readers which implementation the dump
was written by and hands back a shark.HeapMapEntry per entry: the node, the key and the value.
It covers exactly the maps they cover, and which field to read is answered once rather than
twice. Null for an object that is no map, which is worth telling apart from a map with nothing
in it — a map allocates its table on the first put, so an empty one reads as no entries.

Tested against heap dumps of the test JVM itself, so the maps read are the ones the JDK in use
writes: HashMap, LinkedHashMap and ConcurrentHashMap read as their entries, a node is the
node the map holds the entry in, a null value is still an entry, an empty map is no entries, and
a WeakHashMap, a set and an object that is no map each read as no map at all.

Tests

Two new cases on a dump built with the real class and field names of a LinkedHashMap,
table and next included, with two buckets and a chain of two entries so that a walk
that only looked at the buckets, or only at the head of a chain, would come up short. One
asserts that exactly the payloads read as CACHE and every piece of the cache's
bookkeeping stays STRONG; the other that a payload a tile also holds is the tile's, on a
path that doesn't go through the cache.

🤖 Generated with Claude Code