`MemoryCache::Read` fetches a whole L2 cache line for any read that fits
in one,
so reading a few bytes caches the line around them. `ReadRanges` probed
only L1,
and re-fetched ranges that line already held. Callers hit this whenever
they
read an array's header and then batch the elements that follow it in the
same
line, as `AppleObjCRuntimeV2::SharedCacheImageHeaders` and
`ClassDescriptorV2::method_list_t` both do. #201166 uses MemoryCache in
`Process::ReadRangesFromMemory`, but I didn't see why is L1 used only.
Add `FindL2CacheEntry`, a lookup that never reads from the inferior, and
consult
it after L1. When it serves every range in a batch, `ReadRanges` returns
without
calling `Process::DoReadMemoryRanges`, so no packet is sent. As in the
L1 lookup
a range spanning two lines is a miss, and a partially read line is used
only up
to what it holds.
Over the region
`TestObjCMethodsNSError.test_runtime_types_efficient_memreads`
brackets, `MultiMemRead` drops from 190 packets to 107 and the ranges
they carry
from 7004 to 6411, with the `m`/`x` count unchanged at 856. That test
now also
requires no read range to be contained in one an earlier packet already
read,
which counted 593 ranges before this change and none after.
`TestReadMemoryRangesUsesL2Cache` covers the lookup directly.
(cherry picked from commit 797a057bccd4f0e96f2775a55d2e6401e46e0275)
Yao Qi
80e68c79c6