C2 applies a fast/slow path code generation strategy for compiling different constructs (allocations, GC barriers, subtype checks, array copy, intrinsics, etc.). This strategy improves the efficiency of the generated code at the expense of C2 time, native memory usage, code cache size, and C2 node budget. Its underlying assumption is that the generated code is hot, so that the compilation cost is amortized when running the compiled code. Preliminary measurements show, however, that a significant fraction of the C2-generated code can be considered cold within its compilation unit. For example, in DaCapo23 h2 and spring (small), more than 50% of the total C2-generated code has an estimated execution frequency of less than 0.1% of the maximum execution frequency in its compilation unit. For such cold code, the profitability of generating fast path idioms is questionable.

This RFE proposes exploring generating only slow path code for constructs that can be seen as cold by C2, according to some threshold.

EXPERIMENTAL OBSERVATIONS

Here are some experimental results showing the relative hotness/coldness of different code elements generated by C2 for DaCapo23. Here, "cold code" refers to code that is (estimated to be) executed at most N% of the times the most frequent code in the compilation unit is executed. The experiments include results for coldness thresholds N = {10%, 1%, 0.1%, and 0.01%}.

1. The majority of the C2-compiled code is cold.

With a coldness threshold of e.g. 1%, more than 60% of the C2-compiled code is cold. Even with a threshold of 0.01%, around 50% of all C2-compiled code is cold.

(see percent-of-C2-generated-cold-code-for-different-coldness-thresholds-10%-vs-1%-vs-0.1%-vs-0.01%.pdf)

2. A large fraction of the cold code corresponds to handling uncommon traps.

If we discount uncommon trap handling code (cold by definition), the amount of cold C2-compiled code is reduced significantly (e.g. around 26% at 1% or only 14% at 0.01%). This suggests that around a third of C2's generated code is devoted to handling uncommon traps.

(see percent-of-C2-generated-non-trapping-cold-code-for-different-coldness-thresholds-10%-vs-1%-vs-0.1%-vs-0.01%.pdf)

3. A significant fraction of C2-compiled object allocations are cold.

With a coldness threshold of 1%, more than a third of all C2-compiled allocations are cold. The percentage decreases to around 23% (0.1%) and 12% (0.01%). This is perhaps an expected consequence of the usual Java programming advice of "moving allocations out of hot paths".

(see percent-of-C2-generated-cold-allocations-for-different-coldness-thresholds-10%-vs-1%-vs-0.1%-vs-0.01%.pdf)

4. The fraction of cold (G1) GC barriers is similar to that of cold code discounting uncommon trap handling.

With a coldness threshold of 1%, around 30% of all C2-compiled G1 barriers are cold. In general, GC barriers seem to be distributed more uniformly across hot and cold paths than allocations. The percentage of cold GC barriers decreases similarly to that of cold code in general with tighter coldness thresholds.

(see percent-of-C2-generated-cold-G1-barriers-for-different-coldness-thresholds-10%-vs-1%-vs-0.1%-vs-0.01%.pdf)