AllocationRegister is a special-purpose hash map that has a hard limit on number of items it can store. It mmaps() the whole memory region on construction and doesn't allocate any additional memory during its lifetime.

It was created for a simple case of storing 12 pseudo stack frames, where each frame was a pointer. The hard limit was 2621440, so it was mmaping 2621440 * 64 (Backtrace: 48, AllocationContext: 52, Allocation: 60, Cell: 64) = 160 MiB.

Then crrev.com/1921773003 inflated that 4x: frame became 2 pointers wide, and number of frames was bumped to 24. This caused issues on x64 iOS ( crbug.com/608354 ), since it was trying to mmap ~1 GiB (160 * 4 * 2 MiB).

So hard limit of items was halved in crrev.com/1954443002 to workaround the iOS issue.

Then it became apparent that 24 stack frames are not enough for native profiling. Since we couldn't just bump the number of frames, I proposed different Backtrace implementation that is ~2x memory efficient (and doubled number of frames):  crrev.com/2024113002

Then 32-bit CrOS ran into issue similar to x64 iOS. They only have ~310 MiB available, and can't afford many stack frames. Luckily they only need pseudo stack traces, so one possible workaround for them is to #ifdef different stack frame count: crrev.com/2035513002

I think that AllocationRegister should be rewritten to avoid storing duplicate backtraces. In one of my experiments I found that in the browser process there were only 20K of unique backtraces. Compare this to 1.3M of allocations that AllocationRegister is prepared to handle.