On Tue, Dec 7, 2021 at 11:44 PM Stefan Zager <[email protected]> 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 > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAH%2BmL5AM3bvVJ8efJ1wT05z_kGhF77EBz2AEgbYjt6m3%3DhJJbA%40mail.gmail.com.
