Investigate if CC thread is useful at all

RESOLVED WORKSFORME

Status

()

Core
XPCOM
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: smaug, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

It is not clear to me that CC thread makes anything faster, but it certainly complicates
CC code a bit. Perhaps we should try out disabling use of the thread and see whether
the median CC times reported by telemetry are affected.
This was Andreas' idea long ago so he may have more details to offer here. I know we checked to verify that the change kicked CC to a different core than the one running the main thread (preserving the cache for the main thread's core). I don't think we ever expected the change to reduce actual CC times though.
Well, does it help with main thread either? We run CC async so we don't know what we're
going to run right after CC.
I don't think we have any kind of telemetry that is sophisticated enough to measure the effect of a blown thread cache so I really don't know...

On the one hand it seems unlikely that we have other threads that would use as much memory as the CC thread while running so I would expect the CC thread to be an overall win. However, the amount of memory used by the CC thread is probably much less than it was when the CC thread was introduced so it might not be as much of a win as it used to be. Do we have any telemetry on the maximum size of the data structures we fill when analyzing the CC graph?

Measuring the CC times when the CC thread is disabled (as suggested in comment 0) will not really answer this question either, so I don't think we should take the results of such an experiment as a reason to remove the CC thread.
Actually, it's late and I'm not thinking clearly. It's not the amount of memory used by the CC thread that matters; rather, it's the locality of the memory it's accessing. The CC thread can potentially walk over a large chunk of our heap. What other threads could do that while the main thread is blocked?
I don't think any other thread would do it. But we don't know what the main thread will do
right after CC, so I'm not sure I understand why the locality matters here.

But ok, CC telemetry data isn't useful here. Unfortunately we don't have any data to tell whether
CC thread helps here.

I wonder what cost thread switching cause here.
Depends on: 839025
Kyle just noticed that he accidentally turned off the CC thread when he landed bug 839025, and I failed to notice that in review, so I guess we're shipping Firefox 22 with it disabled.  The fact that nobody seemed to notice this for three months suggests it isn't a huge deal to not use it.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
How would we have noticed it? We don't have any telemetry that measures this stuff.
Maybe Dromeo would have gone up?  I dunno.  I thought we had some page fault telemetry, but it looks like no.
You need to log in before you can comment on or make changes to this bug.