RFR: MethodHandles.Lookup. Wrong access verification

[Sebastian Sickelmann]

Thanks.

I would like to add the test[1] prior to fixing it.
JDK 7 shows the same behavior.

As i am not an author of any openjdk-project but i signed the OCA some
time ago i would love to find and sponsor for this[1].

— Sebastian

Am 03.12.2013 01:08, schrieb John Rose:
> 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 <mailto: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
>>
>