1754020 - FOGNop: Enabling components to be instrumented and still support builds outside mozilla-central

Status: NEW

(Toolkit :: Telemetry, task, P4)

Description

[Chris H-C :chutten]

webrender needs to be able to build on its own outside of mozilla-central. SpiderMonkey is used as the engine in GNOME's GJS. But they're both also critical pieces inside Firefox and thus Mozilla has a deep interest in whether they're behaving properly for our users. Thus we want to have instrumentation in these systems, but we don't always want that instrumentation to actually do anything.

So how do we support this?

I don't think we can get away with "just" a no-op Rust Glean SDK: we will need something that smells an awful like one in order to support webrender's use-case, but that'd result in still a lot of code to link for SpiderMonkey's use-case (the C++ API requires a lot of metric maps and stuff).

To sum, this bug is for designing an implementing a system by which modules of Firefox might instrument themselves with FOG-provided Glean APIs, but only optionally having FOG around to implement them (since FOG requires mozilla-central).

Comment 1

[Chris H-C :chutten]

As a first take, combining the various pieces of ideas that have been floating around:

• These builds still require glean_parser (and, in the case of C++, the glean_parser_ext extensions in toolkit/components/glean/build_scripts/)
  • If the standalone builds can't or don't wish to support a python environment in which to run glean_parser, then we'll need to look into ways to generate the APIs for checking in.
• For webrender we might be able to get away without a full no-op solution as Bas seemed willing to link the Rust Glean SDK from crates.io for the standalone build.
  • This won't work for SpiderMonkey for several reasons including 1) GNOME probably doesn't want Glean (at least at the moment), 2) It's C++ and the only C++ integration layer atop the Rust Glean SDK is FOG's.

Comment 2

[Ted Campbell [:tcampbell]]

I'm doing some exploration of the SpiderMonkey scenario in Bug 1780686.

• Standalone Spidermonkey (jsshell for development team; GJS; SpiderMonkey-on-WASI; etc)

  • The per-module metrics.yaml file is very helpful here and generating stubs of metrics is easy with either glean_parser or just a very simple parser. These types of yaml translations are common in existing spidermonkey codebase.
  • The basic interface of metric types used by spidermonkey can be shimmed pretty easily in spidermonkey, and while these might eventually be part of FOGNop, it is not a problem for spidermonkey to maintain itself. Since the probes depend on these interfaces, some amount of stability and build testing is already expected.
  • Overall pretty positive

• SpiderMonkey in Gecko

  • When building as part of Gecko, spidermonkey is still first compiled as a library and then linked into Gecko. This means internals of spidermonkey are not actually exposed to Gecko without building API surfaces.
  • Including the current glean metric type headers right now is a no-go because nsString files cannot be used outside of gecko internals. The spidermonkey build does not define the required MOZILLA_INTERNAL_API options.
  • If I avoid Event metrics, I can use ifdef MOZILLA_INTERNAL_API in the FoG headers to get a build working. I also ifdef out the nsIGleanMetric code which is not needed for SpiderMonkey.
  • If adding ifdef MOZILLA_INTERNAL_API is reasonable, I do have a working prototype in Bug 1780686 that builds browser and shell. We probably want to iterate on the approach here.
  • Note that this is different from the FOGNop problem and is more of an issue that the FoG API surface doesn't build outside of Gecko, even if the library is linked in later.