RFR: MethodHandles.Lookup. Wrong access verification

John Rose john.r.rose at oracle.com
Mon Dec 2 16:08:32 PST 2013


I appreciate the report and the proposed fixes.  We are looking at this seriously.

— John

P.S.  The root issue may be an accidental inheritance of private methods.   I have been thinking for a while that, in the name of compatibility, the JVMS allows an "invokevirtual" invocation to reach a private method, but that this is unfortunate, since "invokespecial" already supplies a more specific way to get to the method.  Likewise, an "invokeinterface" instruction can reach a virtual method of Object, while "invokevirtual" gives a more specific way.  There are a number of odd pathways through the linkResolver, to support these extra combinations, that I would like to regularize or remove.  I think we should investigate tightening up the JVM linkage rules to avoid the extra corner cases.  That will probably have the effect of removing surprise effects like this one, as we continue to extend the JVM linkage rules.


On Dec 2, 2013, at 1:42 PM, Sebastian Sickelmann <sebastian.sickelmann at gmx.de> wrote:

> Hi,
> 
> some days ago i had written[0] that i maybe found a bug in access verification in MethodHandles.Lookup.
> 
> Now i produces webrev's for the two repos jdk and hotspot.
> 
> In the jdk webrev [1] I implemented some additional tests.
> 
> In the hotspot webrev [2] I tried to fix the wrong behavior. I am not sure if it is the right place to fix this.
> It is more an proof-of-concept--like--reverse-engineering-fix that fixes the symptom, and i do not fully
> understand all the things in the patched source. In fact i think that we can move line 187 to 182 instead
> of chaning line 245 in methodHandles.cpp. But as i said i do not fully understand init_method_MemberName
> and all those CallInfo::vtable_call / CallInfo::itable_call / CallInfo::direct_call differences.
> 
> Hope my works helps solving this issue. And i hope it is an issue. And i hope my fix isn't breaking anything else
> so that it was enough to test my fix against my new testcase in MethodHandlesTest.testFindPrivate
> 
> Kind regards
> Sebastian
> 
> [0] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010228.html
> [1] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_jdk/index.html
> [2] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/webrev_hotspot/index.html



More information about the hotspot-dev mailing list