Clustered reference count islands to reduce BackupRefPtr memory overhead

Hi,

Slide 27 of the "MiraclePtr status update" deck from the Memory Safety Summit last year [1] shows that a majority of the memory overhead from BackupRefPtr is due to the padding needed for adding a ref count at the end of the previous slot for each allocation. That slide was hidden, which I assume was probably just due to time limitations, but please let me know if it is instead due to some other reason.

Assuming that the data on that slide is still valid and reasonably up-to-date, I have a clarifying question about the graph showing wasted memory with BackupRefPtr enabled: Are the ref counts themselves included in the "waste" that is shown, or are they counted as "requested memory?"

Regardless, I'm wondering whether a potential alternative approach of clustering ref counts into "islands" of contiguous ref counts has been evaluated. It would look something like this:

+---------+---------+---------+---------++-----------+-----------+-----------+-----------++---------+--
| Alloc 0 | Alloc 1 | Alloc 2 | Alloc 3 || Ref Cnt 0 | Ref Cnt 1 | Ref Cnt 2 | Ref Cnt 3 || Alloc 4 | ...
+---------+---------+---------+---------++-----------+-----------+-----------+-----------++---------+--

I illustrated a cluster of four ref counts, since they're each four bytes and PartitionAlloc uses 16-byte alignment. This would avoid imposing any additional padding overheads.

On the other hand, I realize that this has a variety of drawbacks compared to the current approach, such as:
1. Some previous slots already have enough padding to fully contain the ref count for the next slot, and this approach would not reclaim that space.
2. Computing the location of the ref count for each allocation would become more complicated.
3. Computing the bounds of each slot for bounds-checking [2-4] would become more complicated.
4. Cache locality between an allocation and its associated ref count could drop for some allocations. Conversely, reducing padding overheads would help to improve cacheability overall.

Best regards,
Michael LeMay

[1] "MiraclePtr status update"; https://docs.google.com/presentation/d/1beobMsVRHJZ5Q3GeKsRSxq60SMQ-Y7GxJBrWPelVooc/edit#slide=id.g1a54e9dd755_2_78
[2] "Implement operator + and - for raw_ptr<>"; https://bugs.chromium.org/p/chromium/issues/detail?id=1073933#c327
[3] "Poison end-of-allocation BackupRefPtrs"; https://bugs.chromium.org/p/chromium/issues/detail?id=1073933#c336
[4] "Tighten BackupRefPtr OOB poisoning based on types"; https://bugs.chromium.org/p/chromium/issues/detail?id=1073933#c338