1671808 - Consider global markers, marker filters

Status: NEW

(Core :: Gecko Profiler, task, P3)

Description

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

+++ This bug was initially created as a clone of Bug #1670954 +++

(Florian Quèze [:florian] from Bug #1670954 comment #0)

[...] A simple idea of API would be MarkerThreadId::MainThread() in the marker options.

Done in bug 1670954. So I'm moving the remainder of the discussion to this new bug here.

Thinking further, profiler_add_marker_for_mainthread currently has only one caller: the IO markers. And other things the I/O markers do could be worth generalizing:

• recording the thread ID of the thread where the marker was added
• adding the suffix to indicate that a marker was from "non-main thread", "non-profiled thread", "unregistered thread".

So I'm wondering if we could have a marker option to show the marker on the main thread, that would automatically:

• record the marker on both the thread where the thing occured and the main thread (if different)
• add the relevant suffix to the marker name on the main thread
• record the thread ID.

https://hg.mozilla.org/try/rev/99c581cae1fc8b73124a1f79fdf7f0ac6c5502b7 shows an example case of markers where this behavior would be very nice.

(Markus Stange [:mstange] from Bug #1670954 comment #3)

As for the long-term plan, I think we should always capture (and include in the JSON) all markers from all threads. And then we can display them in the front-end in whichever way we want, probably controlled by the marker schema in some way. For example, for "NewThread" markers, the marker type could declare itself as "global" in the marker schema. And the front-end could then decide to display "global" markers on the main thread, rather than on the thread that emitted the marker. Or in both threads, as suggested in Bug #1670954 comment 0.

(Gerald Squelart [:gerald] (he/him) from Bug #1670954 comment #4)

It'd be great, but my worry is that we then wouldn't control the memory used by all markers that are not in the list of threads in about:profiling, so that could shorten the effective profiling window, especially when we invite devs to add more markers everywhere... 🤔
(Maybe we'll eventually need to pre-filter markers in other ways, e.g., by category?)

... the marker type could declare itself as "global" in the marker schema

This could be a solution to my worry: Only a few markers could declare themselves as "global" and only they would always be recorded.

(Markus Stange [:mstange] from Bug #1670954 comment #5)

I wouldn't limit all-thread marker capturing to "global" markers. I think filtering by category would be a better way to combat excessive buffer use. Maybe it is time to revive the work done in bug 1369955.

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Another thing to consider: If we record markers in all threads, we'll want to output information for all threads with markers (or even all registered threads, which would be easier), so that we can display thread names and other details for all tracks with markers.
This is something I was thinking of doing anyway (following the "fileioall" feature), see bug 1639791.

Comment 2

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Bug 1738627 added "Markers - All Threads" in about:profiling (aka "markersallthreads" in MOZ_PROFILER_STARTUP_FEATURES), which records all markers from all threads, and shows them in their related threads, even if we don't have stack and/or CPU samples for all threads.

This bug here can stay open for the remaining ideas, see the initial comment above for details.