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

[franz1981]

Here we go @stalep now looking how the site looks like 🙏

[Copilot]

Pull Request Overview

This PR introduces the first draft of the "Sharing is (S)Caring" article on Tiered Compilation impacts and adds a JMH microbenchmark demonstrating MethodData counter contention.

• Adds a new AsciiDoc post covering JVM challenges in containers, tiered compilation, MethodData sharing, NUMA effects, and container implications.
• Introduces MethodDataSharing.java, a JMH benchmark to highlight scalability issues in MethodData updates.
• Includes sample benchmark results and external resource links.

Reviewed Changes

Copilot reviewed 2 out of 6 changed files in this pull request and generated no comments.

File	Description
content/post/method-data-scalability/index.adoc	Added draft article content with sections on containerized JVM, tiered compilation, telemetry sharing, and performance implications
content/post/method-data-scalability/MethodDataSharing.java	Added a JMH benchmark class illustrating MethodData counter contention in HotSpot

Comments suppressed due to low confidence (5)

content/post/method-data-scalability/index.adoc:7

• [nitpick] The 'related' field contains an empty placeholder; consider removing it or populating it with actual related post identifiers to avoid rendering an empty link.

related: ['']

content/post/method-data-scalability/index.adoc:62

• [nitpick] Verify that the AsciiDoc link:MethodDataSharing.java reference resolves correctly in your site generator or consider using a full URL or an Asciidoctor include directive if needed.

To demonstrate the scalability issue, we use a micro-benchmark (link:MethodDataSharing.java[this benchmark]) with https://github.com/openjdk/jmh[JMH]. The benchmark focuses on a method with tight loops to highlight the cost of updating `MethodData` counters.

content/post/method-data-scalability/MethodDataSharing.java:18

• The Javadoc comment lists -XX:TieredStopAtLevel= without an example value; consider specifying a placeholder or example like -XX:TieredStopAtLevel=3 to clarify the intended usage.

 * -XX:TieredStopAtLevel=

content/post/method-data-scalability/MethodDataSharing.java:36

• [nitpick] The method name foo is generic; consider renaming it to something more descriptive like countIterations or performLoop to clarify its purpose in the benchmark.

    private static int foo(int count, boolean countAll) {

content/post/method-data-scalability/MethodDataSharing.java:36

• [nitpick] The parameter countAll is ambiguous; consider renaming it to enableCounting or similar to better convey its boolean role.

    private static int foo(int count, boolean countAll) {