MESH: Compacting Memory Management for C/C++ Applications

[Bill Budge]

This is an interesting and surprising way to defragment unmanaged memory heaps using a combination of randomized allocations and memory mapping.

I'm wondering if anyone has considered adopting it in Chromium?

https://arxiv.org/pdf/1902.04738.pdf

[Chris Hamilton]

+chrome-catan 

There was a bit of chatting about this on some other mailing lists last week. The results do look impressive, and given our use of plain old malloc/free and our existing allocator shim mechanism in the browser process, it would be very easy to experiment with there. However, in the renderer process we have a lot of custom allocators in use (partition alloc, oilpan, etc), and using these techniques would be a lot harder because the mechanism would have to be baked into the individual allocator's logic itself.

Experimenting in the browser process sounds like fun though, and falls within the purview of my team so I'll find somebody to take a look.

Cheers,

Chris

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/c8bfeacc-0823-4b87-9e66-97be9e4f7443%40chromium.org.

[Peter Kasting]

TLDR:

• Allocate objects randomly within virtual pages, so that different virtual pages are unlikely to have overlapping objects
• Find virtual pages whose objects don't overlap, and map them to the same physical page, so that the actual physical memory used is more highly compacted
• Testing by running Speedometer in Firefox shows a 16% decrease in mean RSS but <1% drop in Speedometer score

PK

[Primiano Tucci]

+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@.

* https://crbug.com/448968, https://crbug.com/483399, https://crbug.com/481420, https://crbug.com/477444, https://crbug.com/473973, https://crbug.com/249880

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAHOzFCYH_F8k-MvayLwasWb66vn5Z0W%3DZD5e93soyF08MVrGQ%40mail.gmail.com.

[Benoit Lize]

Thanks Primiano for the heads up!

Yes, this is something we intend to work on for Android, namely investigations into malloc() and fragmentation on Android. This was partially started from seeing the paper above. Here is a short explainer of the motivations and some lightweight investigations that we intend to carry in clank fundamentals:

https://docs.google.com/document/d/1idSFlMIjoMXgv46GFTAYmDUxM-jjN6XxXOYok4TLqkQ/edit?usp=sharing

(Sorry, the doc is only open to Google employees. Will see how to make it public)

From this conversation, it's then unlikely that we would try to use mesh on Linux, as desktop folks are already on it :)

[David Turner]

Le lun. 25 févr. 2019 à 10:41, Primiano Tucci <prim...@chromium.org> a écrit :

+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.

Ah, I had not noticed this part. I totally agree that segfaults handlers in Android are really really hard to get right (blame it on the VM and third-party OEM firmware installing their own handlers in the same application process before our own code runs, or sometimes after it started :-/) and we should not try to rely on that at all, except for breakpad/crashpad. Been there, done that, got the t-shirt :-)

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2ByH71dCdpm3%3Do4L31oShjJmFfT5t%2Bj96Wdq_dQzutB3%3DXwNEw%40mail.gmail.com.