Sharing is scaring article

[franz1981]

This is the first draft of the article, which still need to check if the way I created code snippet/links/images/assembly is fine with adoc.

Go at https://github.com/franz1981/redhatperf.github.io/blob/sharing_is_scaring/content/post/method-data-scalability/index.adoc

[franz1981]

There are still few snippet and images links to fix

[franz1981]

In the second part I have to explain why https://github.com/openjdk/jdk/blob/84240cc8e01663196cf883efec4c0eb4ea590c27/src/hotspot/share/compiler/compilationPolicy.cpp#L1039-L046 doesn't save the day, will be fun 😊

And this is what copilot think about it

The CompilationPolicy::common function defines the state transitions for method compilation levels in the JDK. Here are the key transitions:

1. 0 -> 3 -> 4: The most common path where a method starts in the interpreter (CompLevel_none), gathers full profiling data (CompLevel_full_profile), and then is optimized by the highest level compiler (CompLevel_full_optimization).
2. 0 -> 2 -> 3 -> 4: This occurs when the load on the high-level compiler (e.g., C2) is high. The method transitions to a limited profiling state (CompLevel_limited_profile) before gathering full profiling data and then being fully optimized. This helps manage the compilation load.
3. 0 -> (3->2) -> 4: If the C1 queue is long, a method might gather full profiling data at level 0 and then switch to limited profiling while still in the queue, which allows faster execution while waiting for C2 compilation.
4. 0 -> 3 -> 1 or 0 -> 2 -> 1: After initial compilation with C1, a method might be identified as trivial and compiled at a simpler level (CompLevel_simple). This can also happen if a method can't be compiled with the highest level but can be with C1.
5. 0 -> 4: This path can occur if a method fails C1 compilation or due to a deoptimization that doesn't require re-profiling.
   These transitions help manage the compilation workload and optimize performance based on method characteristics and compilation queue lengths.

[franz1981]

I need to quote https://developers.redhat.com/articles/2023/09/29/how-we-solved-hotspot-performance-puzzle as well since it's very relevant

[franz1981]

I think I should add some notes on why the counters kept getting updated even if they pass the thresholds (invocation and back edge counters, really - for the others doesn't make sense to stop collecting)

[franz1981]

I need to link:

• https://mail.openjdk.org/pipermail/hotspot-dev/2024-December/099863.html
• https://developers.redhat.com/articles/2021/11/18/runtime-profiling-openjdks-hotspot-jvm#

with the former actually performing the same exact analysis I made - but with AARCH64 - and reaching the same conclusions (which is great - since it validates them!).

[franz1981]

Here the paper content, publicly accessible: https://ckirsch.github.io/publications/proceedings/MPLR24.pdf#page=117