Bimorphic inlining not applied at a call site that was initially monomorphic

[Roland Westrelin]

> The question is if such a behavior is intentional (I didn't find an issue
> suggesting the opposite)
> and if it is, what differs it from scenarios where a call site is always
> bimorphic and where the C2
> successfully performs inlining (or where the C1 simply can't inline a
> monomorphic vcall initially)?

Thanks for all the details.
I don't think it is intentional. It looks like a bug to me. This:

diff --git a/src/hotspot/share/c1/c1_LIR.hpp b/src/hotspot/share/c1/c1_LIR.hpp
index 6f527135fbe..4ea5b9ebb73 100644
--- a/src/hotspot/share/c1/c1_LIR.hpp
+++ b/src/hotspot/share/c1/c1_LIR.hpp
@@ -2031,7 +2031,7 @@ class LIR_OpProfileCall : public LIR_Op {
   bool should_profile_receiver_type() const {
     bool callee_is_static = _profiled_callee->is_loaded() && _profiled_callee->is_static();
     Bytecodes::Code bc = _profiled_method->java_code_at_bci(_profiled_bci);
-    bool call_is_virtual = (bc == Bytecodes::_invokevirtual && !_profiled_callee->can_be_statically_bound()) || bc == Bytecodes::_invokeinterface;
+    bool call_is_virtual = (bc == Bytecodes::_invokevirtual/* && !_profiled_callee->can_be_statically_bound()*/) || bc == Bytecodes::_invokeinterface;
     return C1ProfileVirtualCalls && call_is_virtual && !callee_is_static;
   }
 };

makes both cases perform the same (that change is likely not the actual
fix).

Can you file a bug?

Roland.