RFR: 8009130 JCK lambda test fails with IllegalAccessException

[Karen Kinnear]

I updated the webrev for review to:

> http://cr.openjdk.java.net/~acorn/8009130.1/webrev/

I thought I had fixed a jvmti redefineclasses problem with the earlier one, but further
testing showed I needed to a better fix, which is in this webrev, which is also against
a more current hotspot-rt.

thanks,
Karen

On Jul 24, 2013, at 5:33 PM, Karen Kinnear wrote:

> 
> Please review fix for access checking and loader constraint checking for default methods:
> 
> http://cr.openjdk.java.net/~acorn/8009130/webrev/
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009130
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013085
> 
> Summary:
> Now that javac is generating bridges for generic signatures in interfaces, and the JVM
> does not need to handle generic signatures and covariant returns in handling default methods,
> it is possible to simplify the handling of default methods.
> 
> Default methods are concrete methods in interfaces. Their inheritance rules simplified are:
> 1. class method or superclass method wins
> 2. if there is a unique nonshadowed default method in superinterfaces it is chosen
> (this logic was not changed, and many thanks to Keith McGuigan for writing that code so well)
> 3. otherwise we get an AbstractMethodError on invocation
> 
> Before this change, we created overpass (VM created bridge methods) added them to
> the methods array and updated the constant pool. This allowed us to add checkcasts for
> input and return arguments. We don't need those anymore so we don't need overpass methods
> for default handling. The overpass methods added invokespecial invocation instructions which
> ran into issues with access checking, i.e. not being able to access the constantpool of the
> invokespecial linktime resolved method, since they did not always have permission to access the
> interface class.
> 
> With this change default methods are added as an array to instanceKlass and to the instanceKlass vtable.
> Invocation method search order:
> 1. local methods
> 2. superclass methods
> 3. default methods
> 4. abstract interface methods
> 
> The default methods retain their superinterface method_holder, i.e. owning klass, so the
> access checking and loader constraint checking all works as expected with no special logic
> needed.
> 
> We continue to use overpasses for default exception handling, e.g. to create a custom
> AbstractMethodError for the conflict case above.
> 
> Tests run - all on linux64:
> jck vm
>  expect a new failure mode for resolveMethod00602m1 and resolveMethod00602m2 in fastdebug
>  - they will get an assertion. They will be in the jck exclude list next week due to an existing bug: 8011311, support for
>  private instance methods in interfaces not working.
> jck lang
> jtreg jdk (concurrency=1) : java.util, java.lang, jdk.lambda 
> nsk vm.quick.testlist, vm.mlvm, vm.quick-jvmti.testlist
> 
> 8009130 package private example
>  specifically fixes:
>        lang/CLSS/clss475/clss47501m21 and clss47501m211
>        lang/INTF/intf024/intf02402m01 and intf02402m11
> 8013085 loader constraint example
> nsk defmeth tests - with and without redefineclasses
>   - passes all tests that passed before this change, other existing bugs prevent complete passing
> Reflect2 - reflection modeling
> reflect.invoke - DefaultStaticTest.java
> intfbug test
> jcmd GC:class_stats
> 
> thanks,
> Karen
> 
> 
>