Does C2 disable incremental inlining for methods without @ForceInline?

[Liu, Xin]

Hi,  hotspot-compiler,

If I understand correctly, C2 has actually disabled incremental inlining for almost all methods without @ForceInline.  Is it intentional?

2 positions check !callee-force_inline().

1. https://hg.openjdk.java.net/jdk/jdk/file/76b9822d2e65/src/hotspot/share/opto/bytecodeInfo.cpp#l368
2. https://hg.openjdk.java.net/jdk/jdk/file/76b9822d2e65/src/hotspot/share/opto/bytecodeInfo.cpp#l474

I ran “dacapo/eclipse” and got 5345 inline failure msg ‘size > DesiredMethodLimit’
If I comment out these 2 checks,  those messages will be all gone.  By checking LogCompilation, I can confirm that 386 more methods are inlined by incremental inlining.

jdk333 is baseline.
jdk335 is with the patch that comments out !callee-force_inline().
diff --git a/src/hotspot/share/opto/bytecodeInfo.cpp b/src/hotspot/share/opto/bytecodeInfo.cpp
--- a/src/hotspot/share/opto/bytecodeInfo.cpp
+++ b/src/hotspot/share/opto/bytecodeInfo.cpp
@@ -365,7 +365,7 @@
                                WarmCallInfo* wci_result, bool& should_delay) {

   if (ClipInlining && (int)count_inline_bcs() >= DesiredMethodLimit) {
-    if (!callee_method->force_inline() || !IncrementalInline) {
+    if (/*!callee_method->force_inline() || */!IncrementalInline) {
       set_msg("size > DesiredMethodLimit");
       return false;
     } else if (!C->inlining_incrementally()) {
@@ -471,7 +471,7 @@
   int size = callee_method->code_size_for_inlining();

   if (ClipInlining && (int)count_inline_bcs() + size >= DesiredMethodLimit) {
-    if (!callee_method->force_inline() || !IncrementalInline) {
+    if (/*!callee_method->force_inline() || */!IncrementalInline) {
       set_msg("size > DesiredMethodLimit");
       return false;
     } else if (!C->inlining_incrementally()) {


386 more methods are late_inlined.

% grep "late_inline method=" jit_jdk333.xml | wc -l
162

% grep "late_inline method=" jit_jdk335.xml | wc -l
548
Eg.
//jdk333.log
@ 3299   org.eclipse.jdt.internal.compiler.parser.Parser::consumeClassOrInterfaceName (19 bytes)   size > DesiredMethodLimit
//Jdk335.log
@ 3299   org.eclipse.jdt.internal.compiler.parser.Parser::consumeClassOrInterfaceName (19 bytes)   inline (hot)
       @ 10   org.eclipse.jdt.internal.compiler.parser.Parser::pushOnGenericsIdentifiersLengthStack (53 bytes)   inline (hot)
       @ 15   org.eclipse.jdt.internal.compiler.parser.Parser::pushOnGenericsLengthStack (53 bytes)   inline (hot)


The reason I ran dacapo/eclipse because I observed the most ‘size > DesiredMethodLimit’ so far.  Unfortunately, I can’t observe performance gain. My understanding is dacapo/eclipse is too big. The background noise can easily overshadow this tiny inlining gain. My understanding is incremental inlining is especially useful when C2 optimizer can slim down methods from over-threshold to below-threshold. I plan to make up a microbench to prove my point. Is it worth digging?

Thanks,
--lx