Bugzilla

Indeed the [Rust API](https://firefox-source-docs.mozilla.org/tools/profiler/instrumenting-rust.html#registering-threads) is not published as a crate but there is no blockers for us to do that. I think it should be possible to do so. Rust-API crate has this [`enabled`](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/tools/profiler/rust-api/Cargo.toml#20-23) feature that you can disable when it's not linked to Gecko, which will make all the calls no-op. But if you wanna be faster, you can use these raw FFI calls: https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/tools/profiler/public/ProfilerBindings.h#39-40 ([usage](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/tools/profiler/rust-api/src/thread.rs#14,21))

For JVM threads, we don't have a way to register them. But the good thing is you shouldn't *need* to register them :). JVM sampler works a bit differently. [When we are starting it](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java#593-599), we are [getting all the active threads](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java#628) and then [filter the ones that match the profiler thread filter](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java#649-653) that's inside about:profiling. So you can try adding the thread names you would like to profile to this thread filter which is a comma separated list.

There is one caveat though, the thread might not be initialized at the time of profiler start. After the profiler start we don't really check them again to see if there are new threads. I think that was because it was quite a bit overhead to get all the threads, but we might want to still do that every 10-100interval or so. Do you know if that's the case these threads?

Indeed the [Rust API](https://firefox-source-docs.mozilla.org/tools/profiler/instrumenting-rust.html#registering-threads) is not published as a crate but there is no blockers for us to do that. I think it should be possible to do so. Rust-API crate has this [`enabled`](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/tools/profiler/rust-api/Cargo.toml#20-23) feature that you can disable when it's not linked to Gecko, which will make all the calls no-op. But if you wanna be faster, you can use these raw FFI calls: https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/tools/profiler/public/ProfilerBindings.h#39-40 ([usage](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/tools/profiler/rust-api/src/thread.rs#14,21))

For JVM threads, we don't have a way to register them. But the good thing is you shouldn't *need* to register them :). JVM sampler works a bit differently. [When we are starting it](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java#593-599), we are [getting all the active threads](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java#628) and then [filter the ones that match the profiler thread filter](https://searchfox.org/mozilla-central/rev/23efe2c8c5b3a3182d449211ff9036fb34fe0219/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java#649-653) that's inside about:profiling. So you can try adding the thread names you would like to profile to this thread filter which is a comma separated list.

There is one caveat though, the thread might not be initialized at the time of profiler start. After the profiler start we don't really check them again to see if there are new threads. I think that was because it was quite a bit overhead to get all the threads, but we might want to still do that every 10-100interval or so. Do you know if that's the case for these threads?