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.sickelm...@gmx.de <mailto:sebastian.sickelm...@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 >> >
