I noticed this:

@ 19   java.lang.invoke.MethodHandle::invokeBasic(L)V (0 bytes)   failed to inline: receiver not constant
@ 19   java.lang.invoke.LambdaForm$DMH/0x000000000f081000::invokeStatic (21 bytes)   force inline by annotation

with the test case of JDK-8319764 that is method invoke at parse time is not constant (first line of the output) and then it's found constant and inlined (second line of the output). We don't want the first line if inlining ends up succeeding. This:

diff --git a/src/hotspot/share/opto/callGenerator.cpp b/src/hotspot/share/opto/callGenerator.cpp
index 971c37e6b45..e5da4e96b67 100644
--- a/src/hotspot/share/opto/callGenerator.cpp
+++ b/src/hotspot/share/opto/callGenerator.cpp
@@ -684,6 +684,7 @@ void CallGenerator::do_late_inline_helper() {
       C->print_inlining_update_delayed(this);
       return;
     }
+    C->print_inlining_update_delayed(this);
 
     // Setup default node notes to be picked up by the inlining
     Node_Notes* old_nn = C->node_notes_at(call->_idx);

appears to fix it. I believe this used to work so a test case would be nice to prevent a regression. I also think I saw the same behavior with late inlining of a virtual call.