java: async-profiler: use dump command for truly continuous profiling #569
Description
We profile with async-profiler by issuing start followed by stop (which stops profiling and dumps the collected traces).
Since async-profiler/async-profiler@868bfec (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:
- More accurate profiling - we are always profiling and not intermittently which may introduce skewing.
- 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.
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.