1366364 - Possible to hit two GCMajor periods in quick succession

Status: RESOLVED DUPLICATE of bug 1374797

(Core :: JavaScript: GC, enhancement)

Description

[Mike Conley (:mconley) (:⚙️)]

Here's a profile:

https://perf-html.io/public/3e4be8ee6a3218e5d5460331df5a26a100bbe8e6/calltree/?range=11.7425_14.6332&thread=5

We've got a long GCMajor period that lasts about 2.5 seconds, and then after that, another GCMajor period of 278ms.

ehsan today suggested that doing two GCMajor's like that is probably undesirable, so that's why I'm filing this.

Comment 1

[Steve Fink [:sfink] [:s:]]

This profile makes me think we shouldn't be displaying MajorGCs at all, since it obscures whatever else is happening at the same time and implies that the user is waiting, which is false. Now that all slices are shown, I think it would be better to only display the slices, during which nothing else can be happening.

I mentioned this to mstange, who says he'll blacklist GCMajor.

As for the timing, what I see is that we do an incremental GC (spread over 2.5s) followed by an ALLOC_TRIGGER slice. That means that we finished a GC, updated the allocation trigger relative to the current amount of live data, then quickly allocated enough GC memory to blow through that threshold.

I don't think we want to make that situation impossible, since the alternative might be OOMing. But maybe this suggests that the GC scheduler should take into account how long it's been since the last GC, and raise the threshold for a while immediately after a GC completes?

Comment 2

[Jon Coppeard (:jonco)]

This sounds like it might be the same thing as bug 1374797.  mconley, are you still seeing this happen?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I have not seen this happen again recently, no. I'll dupe this over to bug 1374797.