RFR: Lambda 8026213: Reflection support for private methods in interfaces

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 10 09:13:54 UTC 2013


On Oct 10, 2013, at 12:13 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:

> 
> Please review:
> 
> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8026213
> 
> Summary:
> Reflection generates code dynamically to speed up reflection processing after startup. The first
> 15 runs of a reflection call  use the vm code path, after that we use the generated code path, which
> needs to use invokespecial on private methods in interfaces.
> 

You don't need to pass modifiers as a parameter to emitInvoke since it is set as a field on AccessorGenerator and used, e.g. see isStatic().

So perhaps add the following method to AccessorGenerator:

    protected boolean isPrivate() {
        return Modifier.isPrivate(modifiers);
    }

and do:

642                 if (isInterface()) {

 643                     if (isPrivate()) {
 644                       cb.opc_invokespecial(targetMethodRef, count, 0);
 645                     } else {

 646                       cb.opc_invokeinterface(targetMethodRef,
 647                                              count,
 648                                              count,
 649                                              typeSizeInStackSlots(returnType));

 650                     }

 651                 } else {
 652                     cb.opc_invokevirtual(targetMethodRef,
 653                                          count,
 654                                          typeSizeInStackSlots(returnType));
 655                 }
 656             }
 657         }

?

Paul.

> Tested:
> Test attached to the bug
> 
> Also - all the 8011311 private method testing was run with this in the build:
> Robert Field's TypeTest
> 8025475 test
> defmeth privatemethodstest with reflection
> John Rose's intfbug
> jtreg: java.util, java.lang
> jck vm, lang
> 
> thanks,
> Karen
> 
> 



More information about the core-libs-dev mailing list