1759550 - Discover & profile JVM threads created during profiling session

Status: ASSIGNED

(Core :: Gecko Profiler, enhancement, P3)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

In the initial implementation of multi-thread support for JVM threads (bug 1618560), we fetch all the matching threads on profiler start and profile those: i.e. we won't profile a thread if it was started during the profiling session.

This bug is to implement this functionality: to actively discover threads during profiling and, if they match our filters, profile them too.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Note: the reason we didn't already implement this is because we're concerned that ThreadGroup.enumerate takes too long to run on every sample (especially at times like 1ms).

Comment 2

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

(In reply to Michael Comella (:mcomella) [needinfo or I won't see it] from comment #1)

Note: the reason we didn't already implement this is because we're concerned that ThreadGroup.enumerate takes too long to run on every sample (especially at times like 1ms).

In case it helps: It's a similar problem with discovering native threads, especially on Windows (it takes multiple milliseconds). So we run the discovery on a separate thread, and run it less frequently than the sampling interval, to keep its overhead small. Of course that means we can miss the beginning of a thread.

Comment 3

[Marc Leclair [:mleclair]]

Attachment: Bug 1759550: Discover JVM threads created during profiling in GeckoJavaSampler

Comment 4

[Marc Leclair [:mleclair]]

Attachment: Bug 1759550: Gecko profiler can capture threads that are created after it is started in Java r=mstange