+lizeb and I had an offline chat on this last week.
lizeb@ did some initial measurements (maybe he has docs to share publicly?) and looks like memory lost due to fragmentation and thread caches might be indeed non-trivial, at least on Android (depends on the system allocator used / Android dessert).
About MESH: I'd refrain from using that as-is, because that involves playing clever tricks with segfault handlers. Segfault handlers are hard to get right and subtly broken on various versions of Android *. I'd like to stick with the current model where nothing but breakpad/crashpad handles segv signals & friend. IMHO it would be a major risk of losing crash reports.
Having said this, there is the chance we could come up with something similarly nice by (handwavy) using a mix of: using PartitionAlloc in some more places; lazily zero freed areas to make them more likely to be compressed by ZRAM (which IIRC is used by both Android and CrOs); solving the very subtle dual-heap problems that arise on android when using the non-system allocator due to the lack of symbol interposition.
From a high level, the main doubt both lizeb@ and I share is: how much thread-caching is still an effective strategy, given that these days threads in chrome behave more like uniform pools and there might be less pinning?
We definitely need more data (e.g. log each allocation/free with their tid running on cluster telemetry) and come up with some more data-driven plan. If anybody is interested in the topic and willing to help out I definitely suggest pinging lizeb@ and start a thread on memory-dev@.