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) {

[stalep]

Looks very good, almost too short :)
One thought was that the ending was a bit short on tips on how to avoid this issue. It's noted, but fairly short. Idk, might be very good as it is.

[franz1981]

Thanks @stalep Yep, I've decided to cut it short to make more clear to more people what it is - even if not super technical
Let's say that is an experiment - if people want more assembly, I'm all in eheh 🗡️

PTAL @stalep I've updated the date

and I could add a

How you can fix it?

There are several ways to fix it, based on which platform the application is running on and at which level is addressed.
If users want to reduce the multi-node scalability impacts, in Openshift is possible to configure a Topology Manager and save pods to run with cpu resources shared among different nodes, constraining it to run on a single one.
Other orchestration mechanisms have similar deployment configuration options.

If users are interested into fixing the root cause which lead to run the application code in Tier 3 unoptimized compilation level (prone to the scalability issue mentioned so far) - they just need to increase the cpu quota/resources enough to sustain the expected peak load whilst performing full JIT compilation (including the more costly Tier 4 C2 one).
In short: know your workload and tune the runtime to not have long compilation pauses due to starved runtime compiler threads!

@stalep it looks complex again to me...mmmm