Trying to fix JDK-8013527 - 1st Prototype

[Johannes Kuhn]

JDK-8013527[1] has somehow become the umbrella bug for "Using 
MethodHandles to call caller sensitive methods leads to interesting 
results".

To recap: A caller sensitive method knows about who called it, and can 
behave differently when called from an other context.
Examples are: Class.forName, MethodHandles.lookup, Method.invoke...

A MethodHandle on the other hand should not be caller sensitive.
To archive this, a MethodHandle will "bind" the lookup class as caller 
for caller sensitive methods.

This is currently done by injecting a hidden class (InjectedInvoker" 
that acts as a trampoline for calling caller sensitive methods.

This injected invoker shares many properties of the original caller:
Same ClassLoader, same Module, same Package, same ProtectionDomain, but 
it's not the same class or a nestmate of it.

For caller sensitive methods that do look at more than just the injected 
invoker, this leads to "unexpected" results when called through a 
MethodHandle:

* MethodHandles.lookup() returns a full privileged lookup for the 
injected invoker.
* jlr.Field.get*/set*, jlr.Constructor.newInstance, jlr.Method.invoke 
may fail with an IllegalAccessException if the target is private. See 
JDK-8257874[2].

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

After reading one of John Rose's comments[3], I thought that this might 
be a way to solve this general problem.

So I implemented some of it here[4].

The basic idea is that there is a private overload of the caller 
sensitive method which accepts the caller as a tailing argument.

The good news:
* tier1 Tests pass.
* ((Lookup) lookup.findStatic(MethodHandles.class, "lookup", 
MethodType.methodType(Lookup.class)).invokeExact()).lookupClass() == 
lookup.lookupClass();
* JDK-8257874 can't be reproduced with Field.* or Constructor.
* Performance is likely better. (InjectedInvoker collects all arguments 
into an Object[].)

The bad news:
* If you use a MethodHandle to call Method.invoke for a caller sensitive 
method, then you can still observe the injected invoker.

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

Moving forward, there are 3 ways:
1. Do nothing. Won't fix any bug.
2. Use the current prototype, and accept Method.invoke is odd when 
calling it through a MethodHandle.
3. Go all in:
   * Require **every** caller sensitive method to have a private overload.
   * Method.invoke will also use that private overload.

The problems with the 3rd approach are:
   * What about methods that can be called virtually? 
(Thread.getContextClassLoader())
   * Requires a few changes to MethodAccessor. Maybe implementing 
JDK-6824466[5] first?
   * What about methods that do stack walks?

I have to think more about the problems listed above - but maybe you 
have some input that could help me on that.

- Johannes


[1]: https://bugs.openjdk.java.net/browse/JDK-8013527
[2]: https://bugs.openjdk.java.net/browse/JDK-8257874
[3]: 
https://bugs.openjdk.java.net/browse/JDK-8020968?focusedCommentId=13611844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13611844
[4]: https://github.com/openjdk/jdk/pull/2117/files
[5]: https://bugs.openjdk.java.net/browse/JDK-6824466