Wallclock is not filtered by `include=`

Author: maciejkwidzinskiCreated Jan 28, 2026Updated Jan 30, 2026

Describe the bug

Can't filter wallclock profiles via AP agent include= option.

Expected vs. actual behavior

Expectation

The JFR contains only a profile of our tests. There should only be one thread called Test worker. All stack traces should contain org.gradle.api.internal.tasks.testing. Both for "Method Profiling Sample"s and "Wall-Clock Sleeping" samples are filtered.

Reality

The profile is not filtered: Image

Method Profiling Sample events are filtered properly: Image

But "Wall-Clock Sleeping" events contain all stacktraces from hundreds of threads: Image

Reproduction Steps

  1. Run via IntelliJ (agent) profiling a Gradle test task.
  2. Use IJ-bundled agent (v4.1) or provide v4.3 manually (doesn't make a difference).
  3. Agent options: event=wall,interval=2ms,include=org.gradle.api.internal.tasks.testing.*.
  4. Wait for tests to finish and IntelliJ profiler GUI to open.

De-facto settings: Image

Additional Information/Context

Workarounds, that don't actually work

Just filter via GUI, select the Test worker thread

It's ok for initial analysis, but:

  • can't diff in GUI, because IJ diff no longer provides the thread picker
    • it would have to join by threads from separate profiles, but there's no generic way to do this: thread ids change, names are not unique and can by dynamic
  • why send 300 MB JFR files, when a much smaller one would suffice

Use filter=

Luckily, the Test worker always has id=1 in IJ profiler GUI. But filter=1 doesn't work. It's because thread filtering is by native thread id, which is not predictable ahead of time.

Filter it via jfrconv

That works somewhat, but:

  • I cannot output JFR with it
  • HTML is cool and all, but IJ can read JFR profiles and display profiling info in code, it's tremendously useful
  • can't diff in IJ
  • it's an extra install step and run step, so my team (and others) will be more reluctant to practice profiling

Method tracing/instrumentation

Docs warn it deoptimizes the method. But I want to measure the slowness that actually happens in practice, including JIT, etc.

Other options

Tried, but without success:

  • wall=2000000
  • filter="Test worker".
  • nobatch All of them individually and various combinations.

Async-profiler version

4.1 and 4.3

Environment details

macOS 26.2 (25C56)

uname: Darwin 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:56 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6041 arm64

OpenJDK 64-Bit Server VM 21.0.7+6-LTS Apple M4 Pro arm64

Source: async-profiler/async-profiler