When to take memory dump of Oilpan

[Kentaro Hara]

(Moving the discussion from IM to this mailing list.)

Context: https://codereview.chromium.org/1149673002/

The problem is how to take memory dump of Oilpan.

Option 1: Take the memory dump at all GCs and return the latest dump when onMemoryDump is requested.

Option 2: When onMemoryDump is requested, force a GC (which disables sweeping) and get the dump.

======

Feedback from ssid@

The other problem I see with doing a GC for memory measurement is that, the freelist statistics are desired to be collected after sweeping, and the memory stats for pages are collected at postGC before sweeping. So, doing a marking without sweep, doesn't help in collecting freelist stats. Do you think I should call collectGarbage, at the dump point? so that both of these are collected at right times? or is it not necessary to have freelist stats to be taken at the preSweep?

Maybe it should store the dump after each sweep and after postGC. and request a global dump so that these dumps can be used and be consistent with the other dumps numbers. (there is very less time diff between the GC and the actual onMemoryDump() call).

That is why I took the second approach which stores the dump at each GC. The problem with this is that the inconsistency could happen if a global dump request fails (when already a dump is being taken in the chrome). To resolve this, maybe we could invalidate the dump after a timeout? typically a dump takes 20ms-100ms. So the memory-infra has an inherent delay for measuring the stats across processes.

but we could end up with too many dumps because it is done at every GC (not clear how frequent GC happens)

it is also not clear to me which option seems better!

--

Kentaro Hara, Tokyo, Japan

[Kentaro Hara]

I think we want to have two kinds of memory dumps:

(a) Memory dump that takes stats without triggering a GC.

(b) Memory dump that forces a GC and takes stats just after doing the GC.

I think (a) is more important to understand the actual memory usage of a renderer process. (b) is important to diagnose how helpful Oilpan's GC is to change the memory usage. We might want to make (a) enabled by default and (b) optional.

So the problem would be how to implement (a).

One approach would be to take memory dumps at all GCs and return the latest dump when onMemoryDump is requested (i.e., ssid@'s CL: https://codereview.chromium.org/1149673002/). However, I'm a bit afraid that it will end up with dumping incorrect stats because it sometimes happen that GC doesn't happen for several seconds. A more straightforward approach would be to force a GC (that disables sweeping) and take the memory dump at postGC().

You'd argue that freelist stats won't be correct at the point of postGC(), but I think that is fine. You can just take freelist stats at postGC(). This would make sense because what we want to dump here is just a status of the heap at that point without triggering any GC. The reason we force a sweep-disabled GC is just to stop all other threads and take stats of live objects. It is not intending to sweep objects and dump stats after the sweeping (that is not what we want to dump in (a)).

So I'd suggest Heap::collectGarbageWithoutSweeping (I can implement it) and use it for the memory dump, but what do you think?

[Keishi Hattori]

I haven't read the entire discussion yet but here'S what I think.
There's stats about the heap and there's stats about the gc. Memory dump should be collecting the former so I think option 2 should suffice. By doing a gc witout sweep we are scanning the heap.for information. I also think freelist stats don't have to be right after a sweep to be useful.

[Siddhartha S]

If it is the case that all the stats can be taken after the marking, then I agree it's better to force a GC at each memory dump.
This means that we are not implementing option a.

Please note that the frequency of the dump will not depend on the number of GCs. If there's an internal where there were multiple GCs happen, then these stats would be lost. This can be dealt with in future.

For now, taking stats after collectGarbageWithoutSweeping sounds good. Thanks for the help Kentaro.

Thanks
Siddhartha.

[Kentaro Hara]

Please note that the frequency of the dump will not depend on the number of GCs. If there's an internal where there were multiple GCs happen, then these stats would be lost. This can be dealt with in future.

I think this is fine (and expected). The timing the dump is taken and the timing GCs happen should be independent.

In the future, we might want to implement another dump that forces a GC to understand the GC impact, but that is a different discussion.

For now, taking stats after collectGarbageWithoutSweeping sounds good. Thanks for the help Kentaro.

OK, it seems like we're on the same page :) I'll try to implement it shortly.

[Kentaro Hara]

Uploaded a CL that implements a GC to take a heap snapshot:

https://codereview.chromium.org/1159773004/

[Primiano Tucci]

I think (a) is more important to understand the actual memory usage of a renderer process. (b) is important to diagnose how helpful Oilpan's GC is to change the memory usage. We might want to make (a) enabled by default and (b) optional.

Completely agree. MemoryInfra should be an observation tool (at least with default settings). We want to avoid that getting the dumps will magically free objects that wouldn't have been freed otherwise (unless the user ticks some special settings, which is your optional (b) ).

It seems that the right way to go here is to do a forced-non-sweeping GC on demand and take the heap snapshot.

> By doing a gc witout sweep we are scanning the heap.for information. I also think freelist stats don't >have to be right after a sweep to be useful.

Keishi: so, let me check if my understanding is correct here. Does this mean that if we dump freelists during the forced-non-sweeping-GC that is going to produce still relevant data and is worth getting started with that as well?

Thanks folks!

[Kentaro Hara]

> By doing a gc witout sweep we are scanning the heap.for information. I also think freelist stats don't >have to be right after a sweep to be useful.
Keishi: so, let me check if my understanding is correct here. Does this mean that if we dump freelists during the forced-non-sweeping-GC that is going to produce still relevant data and is worth getting started with that as well?

If you take a snapshot of the freelist in the forced-non-sweeping GC, you can *just observe* a snapshot of the freelist used by mutators at that point (Remember that the forced-non-sweeping GC does *nothing*).

[Keishi Hattori]

Yes. And observing the freelist at that point is useful to see if allocations made by the mutator is utilizing the freelist properly, not allocating new pages because the free regions are too fragmented.

--

- Keishi