Open Bug 1223458 Opened 4 years ago Updated 3 years ago

Allocate TabChildGlobals in separate zone(s)

Categories

(Core :: JavaScript: GC, defect)

defect
Not set

Tracking

()

UNCONFIRMED

People

(Reporter: bugzilla.mozilla.org, Unassigned)

Details

Based on discussion in bug 1160228 comment 14 and following:


I am speculating that in profiles with many tabs the frame scripts increase the footprint of the system zone so much that the minimum non-incremental GC overhead for that zone becomes so large that it does exceed the GC slice budget.

I think a simple solution would be to split out TabChildGlobals into separate zones. Maybe 1 new zone every N frames to avoid per-zone overhead. Intuitively this makes sense to me because frames have different object lifetimes than the stuff in the system zone and also different allocation behavior. Some JSMs will always be allocating something in the system zone and thus requiring GCs while background frames should be mostly quiescent and thus shouldn't need to be visited by the GC when the system zone is.



about:memory excerpt:


│  ├──1,097.10 MB (40.18%) -- zones
│  │  ├──1,012.86 MB (37.09%) -- zone(0x6bba000)
│  │  │  ├────790.46 MB (28.95%) -- compartment([System Principal], outOfProcessTabChildGlobal)
│  │  │  │    ├──531.75 MB (19.47%) -- classes
│  │  │  │    │  ├──218.12 MB (07.99%) -- class(Function)
│  │  │  │    │  │  ├──203.81 MB (07.46%) -- objects
│  │  │  │    │  │  │  ├──195.87 MB (07.17%) ── gc-heap [1885]
│  │  │  │    │  │  │  └────7.94 MB (00.29%) ── malloc-heap/slots [1885]
│  │  │  │    │  │  └───14.31 MB (00.52%) ++ shapes
│  │  │  │    │  ├──156.38 MB (05.73%) -- class(<non-notable classes>)
│  │  │  │    │  │  ├───98.86 MB (03.62%) -- shapes
│  │  │  │    │  │  │   ├──82.41 MB (03.02%) -- gc-heap
│  │  │  │    │  │  │   │  ├──61.79 MB (02.26%) ── tree [1885]
│  │  │  │    │  │  │   │  └──20.63 MB (00.76%) ++ (2 tiny)
│  │  │  │    │  │  │   └──16.45 MB (00.60%) ++ malloc-heap
│  │  │  │    │  │  └───57.52 MB (02.11%) -- objects
│  │  │  │    │  │      ├──31.30 MB (01.15%) ── gc-heap [1885]
│  │  │  │    │  │      └──26.22 MB (00.96%) ++ malloc-heap
│  │  │  │    │  ├──116.92 MB (04.28%) -- class(Object)
│  │  │  │    │  │  ├───82.79 MB (03.03%) -- shapes
│  │  │  │    │  │  │   ├──67.19 MB (02.46%) -- gc-heap
│  │  │  │    │  │  │   │  ├──63.96 MB (02.34%) ── tree [1885]
│  │  │  │    │  │  │   │  └───3.23 MB (00.12%) ++ (2 tiny)
│  │  │  │    │  │  │   └──15.60 MB (00.57%) ++ malloc-heap
│  │  │  │    │  │  └───34.12 MB (01.25%) ++ objects
│  │  │  │    │  ├───40.15 MB (01.47%) ++ class(Block)
│  │  │  │    │  └────0.18 MB (00.01%) ++ class(Array)
│  │  │  │    ├──168.60 MB (06.17%) -- scripts
│  │  │  │    │  ├──138.68 MB (05.08%) ── gc-heap [1885]
│  │  │  │    │  └───29.92 MB (01.10%) ── malloc-heap/data [1885]
│  │  │  │    ├───36.94 MB (01.35%) ── compartment-tables [1885]
│  │  │  │    ├───28.70 MB (01.05%) -- type-inference
│  │  │  │    │   ├──28.68 MB (01.05%) ── object-type-tables [1885]
│  │  │  │    │   └───0.02 MB (00.00%) ── type-scripts [2]
│  │  │  │    └───24.48 MB (00.90%) ++ (2 tiny)
│  │  │  ├────102.92 MB (03.77%) ++ (216 tiny)
│  │  │  ├─────50.77 MB (01.86%) -- object-groups
│  │  │  │     ├──50.38 MB (01.84%) ── gc-heap
│  │  │  │     └───0.39 MB (00.01%) ── malloc-heap
│  │  │  ├─────37.52 MB (01.37%) ── unused-gc-things
│  │  │  └─────31.18 MB (01.14%) ── type-pool
│  │  └─────84.24 MB (03.09%) ++ (56 tiny)


snip from GC logs (I'm seeing larger max pauses too, but it's not always easy to find the corresponding slices since there are hundreds):


[...]
10:22:10.407 GC Slice 27 - Pause: 40,641ms of 40ms budget (@ 4050,017ms); Reason: INTER_SLICE_GC; Reset: no; Times: Mark: 38,538ms
10:22:10.537 GC Slice 28 - Pause: 29,873ms of 40ms budget (@ 4192,186ms); Reason: INTER_SLICE_GC; Reset: no; Times: Mark: 28,044ms, Other: 28,000ms
10:22:11.085 GC Slice 29 - Pause: 442,845ms of 40ms budget (@ 4322,175ms); Reason: INTER_SLICE_GC; Reset: no; Times: Sweep: 433,195ms, Other: 32,730ms, Mark During Sweeping: 303,074ms, Mark Incoming Black Pointers: 0,187ms, Mark Weak: 26,893ms, Mark Incoming Gray Pointers: 0,136ms, Mark Gray: 271,176ms, Mark Gray and Weak: 4,591ms, Finalize Start Callbacks: 16,316ms, Per-Slice Weak Callback: 4,162ms, Per-Compartment Weak Callback: 12,152ms, Sweep Compartments: 54,453ms, Sweep Discard Code: 20,014ms, Sweep Inner Views: 0,300ms, Sweep Cross Compartment Wrappers: 49,080ms, Sweep Base Shapes: 5,087ms, Sweep Initial Shapes: 12,153ms, Sweep Type Objects: 27,533ms, Sweep Breakpoints: 0,546ms, Sweep Regexps: 0,716ms, Sweep Miscellaneous: 11,309ms, Sweep type information: 0,200ms, Sweep type tables and compilations: 0,179ms, Sweep Object: 26,198ms, Sweep String: 0,181ms, Sweep JIT code: 0,120ms
[...]
GC(T+110257.6) Summary - Max Pause: 442,845ms; MMU 20ms: 0,0%; MMU 50ms: 0,0%; Total: 2179,753ms; Zones: 1870 of 1870; Compartments: 4112 of 4112; HeapSize: 1052,613 MiB; HeapChange (abs): +0 (0);
This could be quite useful, especially if we want per tab-group GCs or so.
You need to log in before you can comment on or make changes to this bug.