1530397 - Servo "divs wave" demo spends 55ms in GCMinor after every 330ms, and memory keeps on increasing continuously

Status: NEW

(Core :: JavaScript: GC, defect, P3)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

go to https://mozdevs.github.io/servo-experiments/experiments/divWaves/

Profile : http://bit.ly/2Nwibfi

Actual results:

large-ish time spent in GCMinor

Expected results:

maybe not so?

Comment 1

[Paul Bone [:pbone]]

This benchmark is allocating a lot of objects, some in a store buffer, that are evicted. Our GC doesn't currently tune itself well to these situations, but Bug 1397549 will help, it'll trade some throughput for better responsiveness here.

It's worth noting that the tenure rate (MB/s) in the profile is fairly typical, which is what allows me to narrow it down just to a tuning decision (maybe a pretenuring decision) for this particular workload.

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz

I just noticed today that memory steadily climbs on that page. If you let it run for a 1 minute or so, memory will reach 1.3GB+ , and continue to climb. Of course, as soon as you close the tab, the memory is released.
While the animation is running, minimizing the memory takes a very long time, and doesnt really release that much memory.

Comment 3

[Paul Bone [:pbone]]

We should determine if this is a bug/leak in Firefox or in the demo.

Mayank, did you test some other browsers?

Comment 4

[Mayank Bansal]

(In reply to Paul Bone [:pbone] from comment #3)

We should determine if this is a bug/leak in Firefox or in the demo.

Mayank, did you test some other browsers?

Chrome also exhibits ever increasing memory. In fact, memory growth is much faster in Chrome

Comment 5

[Paul Bone [:pbone]]

Okay.

It's actually easier when chrome is faster/uses less memory. because then we know we can/should improve our engine. But in this case we can't (yet) rule out a leak in the test.

I'm looking at the profile again, there's a rather large non-incremental slice due to GCBytesTrigger, So I'm adding this to the GCScheduling meta-bug.

There's also a lot of pretenuring going on and a rather large nursery. I'll take a deeper look soon.

Comment 6

[Mayank Bansal]

Would it be better for bug tracking if I split the "increase in memory" part to another bug, and leave this one for the GCMinor stuff?

Comment 7

[Paul Bone [:pbone]]

Probably not, The work to fix the bug will probably occur under other bugs that are part of those meta bugs, then we'll re-look at how this test case behaves here in this bug and close it when it seems acceptable.

Comment 8

[Paul Bone [:pbone]]

The janky MajorGCs are what concern me with this test, I can see them janking up the animation and in the profiler. So I'll get to that as the major problem.

However the MinorGCs are also taking too long, average 68.2ms, this will cause dropped frames. A lot of data/memory is being tenured which is why they take so long and that may be a problem. But Bug 1397549 and Bug 1538053 will both work to make these collections smaller.

Comment 9

[Mayank Bansal]

For some fun, I let the demo run until it was using 2GB+ memory, and then I started the profiler. Here is the profile i captured:

https://perfht.ml/2YMPUsI

Comment 10

[Mayank Bansal]

Parallel marking seems to be working on this testcase: https://share.firefox.dev/41s5Y0o
And another profile: https://share.firefox.dev/3xQOcGF

Comment 11

[Jon Coppeard (:jonco)]

Bug 1579426 helped here by increasing the slice time for long running GCs, which seems to avoid the really long slices.

This is a good testcase for parallel marking too.

Comment 12

[Mayank Bansal]

Latest profile : https://share.firefox.dev/3HvzcDa