1899578 - Attribute helper thread GC work in the profiler

Status: NEW

(Core :: JavaScript: GC, enhancement, P2)

Description

[Jon Coppeard (:jonco)]

I don't know how to do this but it would be useful if GC work on helper threads showed up in orange and was categorized as GC work as happens for the main thread.

Comment 1

[Nicolas B. Pierron [:nbp]]

Maybe Julien would know.

Comment 2

[Julien Wajsberg [:julienw]]

I can see how that could be useful indeed.

Do we have the markers for them already? Can you point to me where they're created?
Do you want them to show up in the timeline part (that is the top part of the UI)?
It's also good to consider whether this would be useful for more than just your team, and also web developers, as a way to not clutter the timeline part.
But even if that's not super useful for other populations, that could be still OK given that we have some ongoing work to be able to filter out less interesting markers for web developers.

You can define where markers are displayed directly in the Gecko code. If you want them to show up in the orange marker track in the timeline you can define the location TimelineMemory, like in https://searchfox.org/mozilla-central/rev/b476ffaef761ff85c012e2d93050cf444ff7be34/dom/base/CCGCScheduler.cpp#175.

It's possible that we display them only for the main thread currently, but that would be trivial to change in the frontend if everything else is in place.

Comment 3

[Steve Fink [:sfink] [:s:]]

I think the problem is likely that this is coming from SpiderMonkey, which does not have direct access to the full profiler API. We instead poke callbacks through using a js public API.

That said, things like MarkerSchema::Location are in mozglue and therefore accessible, so it wouldn't be horribly difficult to poke a few more things through. I don't think we need them in the timeline, though. Just having the right category when selecting a thread would be good enough. They're already always going to be within a GCSlice marker, at least until Jon goes wild and implements concurrent marking.

I was planning on expanding the API a bit to handle the relevant markers here, since it bothered me to have separate markers for the wait begin and wait end rather than a single interval marker. I think it would just be a matter of passing through the GCCC_MajorGC category pair.