RFR: 8274983: C1 optimizes the invocation of private interface methods [v2]

[Xin Liu]

On Wed, 24 Nov 2021 10:19:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - 8274983: C1 optimizes the invocation of private interface methods
>>  - Merge branch 'master' into JDK-8274983
>>  - 8274983: Pattern.matcher performance regression after JDK-823835
>>    
>>    This patch allows c1 to generate the optimized virtual call for invokeinterface
>>    whose targets are the private interface methods.
>>    
>>    Before JDK-823835, LambdaMetaFactory generates invokespecial in this case. Because the private
>>    interface methods can not be overrided, c1 generates the optimized virtual call. After JDK-823835,
>>    LambdaMetaFactory generates invokeinterface instead. C1 generates the regular virtual call because
>>    it can not recognize the new pattern. If a multiple of subclasses all implement a same interface,
>>    it is possible that they trash the IC stub using their own concrete klass in runtime.
>>    
>>    Optimized virtual call uses relocInfo::opt_virtual_call_type(3), It will call VM
>>    'resolve_opt_virtual_call_C' once and resolve the target to the VEP of the nmethod.
>>    Therefore, this patch can prevent the callsite from trashing.
>
> src/hotspot/share/c1/c1_GraphBuilder.cpp line 1902:
> 
>> 1900:       Value receiver = state()->stack_at(index);
>> 1901:       CheckCast* c = new CheckCast(receiver_constraint, receiver, copy_state_before());
>> 1902:       c->set_incompatible_class_change_check();
> 
> set_incompatible_class_change_check() seems OK for invokeinterface, but for invokespecial, I believe the interpreter throws IllegalAccessError.

Thanks to point it out.  

I take a look at invokespecial and invokeinterface part of JVM spec. There are multiple cases. I think I better use uncommon trap and let interpreter to cover them all. It's not a hot path anyway. 
 
By reverting this code, `java/lang/invoke/SpecialInterfaceCall.java` is fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6445