RFR: 8009130 JCK lambda test fails with IllegalAccessException

[Karen Kinnear]

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