Open Bug 1283251 Opened 8 years ago Updated 1 year ago

Add memory reporter for worker cycle collectors

Categories

(Core :: Cycle Collector, defect, P5)

defect

Tracking

()

Tracking Status
firefox50 --- affected

People

(Reporter: mccr8, Unassigned)

References

Details

(Whiteboard: [MemShrink:P3])

In bug 1205110, the purple buffer is getting weirdly large, so I started looking at how we do reporting for it. The way it works now is that there is a static bool that is checked before we register, and then is set to true once we register. I think in practice this means we never register worker CCs with the memory reporter.

However, this is actually good in some sense, because I believe the reporter callbacks are triggered from the main thread, and it is really not okay to just call into the worker CC from the main thread.

I'm not even sure why the static bool is needed (we should only call RegisterJSRuntime once), but it looks like it is good that it is there. This could be made less sketchy by only attempting to register on the main thread. WorkerPrivate::BlockAndCollectRuntimeStats could possibly call directly into the CC reporter to get stats.
Workers don't stress the CC very much, so this isn't a high priority. The bigger issue is probably the questionable way the mainthread only check is enforced, via a racey static variable.
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P3]
Depends on: 1301796
Eric, is there any trickiness to registering a memory reporter from off main thread? I don't remember exactly if that workers. It might be that with bug 1301796 in place, the main thread check would just be removed and this would work.
Flags: needinfo?(erahm)
(In reply to Andrew McCreight [:mccr8] from comment #2)
> Eric, is there any trickiness to registering a memory reporter from off main
> thread? I don't remember exactly if that workers. It might be that with bug
> 1301796 in place, the main thread check would just be removed and this would
> work.

Registering and unregistering is thread-safe. The reporter itself will be called from the main thread which is where things might get tricky. It's possible you'll want to go with an async reporter (RegisterWeak/StrongAsyncMemoryReporter) so that you can proxy a call to the worker thread.
Flags: needinfo?(erahm)
Ah yes, that would require a bit of work. Thanks for the explanation.
This would still be nice to have...
Priority: -- → P5
Severity: normal → S3
Component: XPCOM → Cycle Collector
You need to log in before you can comment on or make changes to this bug.