java: async-profiler: use dump command for truly continuous profiling
- Dominant language
- Python
- Stars
- 826
- Forks
- 79
- PR merge metrics
- No merged PRs in 30d
Description
We profile with async-profiler by issuing `start` followed by `stop` (which stops profiling and dumps the collected traces).
Since https://github.com/jvm-profiling-tools/async-profiler/commit/868bfec2a5eb0a7cc9622a3cb7050e0db71fed45 (1~ year) there is a dump command which dumps the collected traces WITHOUT stopping. I was under the impression that it does stop, but realized now during routine reading of the code that it doesn't.
This has several benefits:
1. More accurate profiling - we are always profiling and not intermittently which may introduce skewing.
2. Possibly better performance - async-profiler needn't perform repeated init/cleanup work due to repeated start/stop (that I assume, didn't verify though).
It's similar to the change we did with `perf` [here](https://github.com/Granulate/gprofiler/pull/113).
What I propose is, we use the `dump` command, and upon next iterations, the `JavaProfiler` will keep the list of "enabled" processes (we can keep the `AsyncProfiledProcess` itself) and instead of re-starting, we can only perform the `status` command to verify AP is truly running (or just skip it and trust AP to be running), wait the interval then issue another `dump`.
We will need to change the cleanup code - currently there is no cleanup done outside of the scope of `_profile_ap_process`. I figure we could do something similar to `SystemProfiler.stop`, which stops ongoing `perf.map` generation in running NodeJS processes in attach-maps mode - we can stop all active APs in `JavaProfiler.stop` (similarly to `clean_up_node_maps` called from `SystemProfiler.stop`).
Please add relevant tests that use the continuous feature over a few snapshot cycles of gProfiler, and prove that data is sent produced properly each time.
Contributor guide
Assessment
This issue has not been assessed yet.