Process Reuse avoiding OOM

[Dave Tapuska]

I'd like to explore implementing a simple algorithm for determining whether we should reuse a process based on its current memory limit.

I believe bashi@ explored something similar https://chromium-review.googlesource.com/c/chromium/src/+/4855863 but that used a fixed limit and obtained memory information from the renderer.

I propose estimating the top level memory usage based on the number of top level frames (not ideal, but it's my best guess right now).

I wrote a simple doc so we could collaborate there instead of on an email thread or CL. Again this is my first thoughts, so would love more ideas/comments.

dave.

[Alex Moshchuk]

Hey Dave,

We took a quick look at this in a CSA sync, and on a high level this seems good, and it's great that it can be potentially generalized for reuse policies beyond process-per-site (e.g., when over process limit or for REUSE_PENDING_OR_COMMITTED_SITE).  The biggest question for us was similar to the doc comment about subframes - can this still deal with processes that only have OOPIFs (which are quite common) or when deciding which process to reuse for an OOPIF, should we be counting subframes (and workers, for that matter) but weighing them less, etc.  But maybe this matters more for general reuse than process-per-site. One other question, which also came up in bashi@'s CL, was whether the PMF measurements are readily available on all platforms and whether we'd end up trusting the renderer to provide any of them. Overall, though, seems like a good direction to experiment with, thanks for exploring it!

Alex