GC during BeginMainFrame

[Stefan Zager]

Hey all,

I've noticed that we will sometimes run GC during BeginMainFrame (see trace below). This seems sub-optimal, as BeginMainFrame is a critical function with a tight deadline for updating the display. Would it be feasible, in the absence of memory pressure, to postpone GC until after BeginMainFrame finishes?

Thanks,

Stefan

[Michael Lippautz]

On Tue, Dec 7, 2021 at 11:44 PM Stefan Zager <sza...@chromium.org> wrote:

Hey all,

I've noticed that we will sometimes run GC during BeginMainFrame (see trace below). This seems sub-optimal, as BeginMainFrame is a critical function with a tight deadline for updating the display. Would it be feasible, in the absence of memory pressure, to postpone GC until after BeginMainFrame finishes?

We generally don't directly postpone GCs in that we forbid them to run in e.g. BeginMainFrame. (There's exceptions but they often make the situation worse as memory needs to be processed eventually.)

That said, we do adjust heuristics and maybe there's something off in this particular case.

In the screenshot below I also see that the GC has already been started before BeginMainFrame and we are not keeping up with marking which is why we mark on allocation of a new object. Large phases of "MarkProcessBailOutObjects"  indicate we are dealing with types that we cannot process concurrently. Maybe there's something we can do there as well which would improve this scenario.

Can you file a bug against Blink>GarbageCollection? Ideally with a repro and/or trace :)

Thanks, -Michael