748680 - Huge GC durations when cpu load is high

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: MemChaser log

So I have had problems with unmounting a DMG image on OS X and the process took about 30% of cpu load. With all other applications running my box was utilized with about 55%. This cpu load caused GC durations of about 600ms up to 2000ms for me all the time.

I wonder what we can do to shorten GC times if Firefox doesn't get so many cpu cycles to complete a CC/GC in a short time.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Is it something we could solve with incremental GC?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Incremental GC would indeed spread the work to longer time, so that there shouldn't be long
GC pauses.
Do you know what is causing the huge GC times? Could you perhaps reload each tab one by one
and wait for some time to see if it helps.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It's really not related to the tab itself but to other processes. For example let a process run beside Firefox which will consume a good chunk of cpu power. You will directly see that Firefox will become sluggish after a short time.

Comment 4

[Marco Castelluccio [:marco]]

I've seen a similar behaviour on Windows 7 while using other heavy applications. At the beginning I thought it was a IO issue.
I've incremental GC enabled.

(I can simply reproduce the issue by updating a svn repository)

Comment 5

[Andrew McCreight [:mccr8]]

Where is it spending the time?  Marking or sweeping?  The GC does some parallel sweeping.  I've often wondered if the GC and CC should disable their attempts at using other cores if you are on a dual core system, and the other core is under a heavy workload.  If the GC/CC is only occasionally using the other core, maybe it gets lower priority, or ends up having to flush caches?

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Yeah, a GC log file with the new JSON output would be much more useful.

Comment 7

[Wayne Mery (:wsmwk)]

Henrik, can  you obtain a new log per comment 6?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: MemChaser log

Updated log from memchaser with high total_time values while restoring a saved VM via Fusion on OS X. This always causes a high cpu load on my machine.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Had it again yesterday in combination with Fusion as described already in comment 8. Firefox was no responsible for several minutes and GC times have shown values >60s. Other applications were working fine, so not sure which component in Firefox is blocking us in this case.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

When you see this, is your system almost out of memory (which would lead to swapping)?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No, there are still about 2GB of free memory available.

Comment 12

[Terrence Cole [:terrence]]

Henrik, is this still happening for you, or have all the GC scheduling changes we've made in the last few months fixed it?

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I haven't seen that massive GC durations as reported earlier but mostly I still have iGC durations of >50ms up to 200ms. Have all the fixes also been landed on Aurora or are the latest ones only available for Nightly? I usually don't use Nightly for my daily testing.