RFR: 8112: Flamegraph model creation performance improvements [v4]

[Christoph Langer]

On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte <duke at openjdk.org> wrote:

>> This pull request improves the performance of creating the model that the flame graph visualization is drawn from.
>> 
>> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task.
>> The use case where that tends to happen to me goes as follows:
>> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test.
>> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two"
>> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread.
>> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it.
>> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app)
>> 
>> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel.
>> 
>> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time.
>> 
>> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick:
>> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee...
>
> Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header with 2023

> ok, I also do not have anything to add here until maybe another reviewer raises issues /integrate

As I said above, I can't sponsor it at this time since I didn't review the actual code changes. Also I'm formally not a Reviewer here (yet), so it needs another review from at least a Committer.

-------------

PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1658195369