RFR (M) JDK-8033150 (#2): invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults

Karen Kinnear karen.kinnear at oracle.com
Fri Apr 11 16:58:18 UTC 2014


I like the enum change. I agree with Coleen's suggestion of leaving out the vmstructs change.

I had one question - instanceKlass.cll uncached_lookup_method -
would it make sense to have a local holding the mode rather than overwriting the input argument of
mode? Wouldn't that be better as a const input argument?


On Apr 11, 2014, at 9:04 AM, Lois Foltan wrote:

> Please review the updated fix, webrev at:
>     http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
> This includes Keith's suggestion below.  All testing has been rerun successfully.
> Thank you,
> Lois
> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>> Hi Lois, 
>>> I think that looks good.  I like it much better than doing the static method check in the default method processing.
>>> My only suggestion is that it would be nice to encode new parameter to uncached_lookup_method to be some sort of enum instead of a boolean, so that it is obvious from the call-site what the behavior should be (having just "false" in the parameter list requires you to reference back to the declaration to figure out what that "false" means).
>>> So instead of: 
>>>    uncached_lookup_method(field_name, field_sig, false);
>>> It'd be:
>>>   uncached_lookup_method(field_name, field_sig, NORMAL); or 
>>>   uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);   
>>> (or something like that -- I'm no good at names).
>> Thank you Keith.  Good suggestion.  I will implement and repost an updated webrev for review.
>> Lois
>>> --
>>> - Keith 
>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan <lois.foltan at oracle.com> wrote:
>>> Hi,
>>> Please review the following fix:
>>> Webrev:
>>>     http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>> Bug: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults
>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>> Summary of fix:
>>> During default method processing, determine_target(), is responsible for making decisions on whether
>>> to create and add an overpass method to the current class for issues that have been encountered during the walk
>>> of the default methods.  The routine defaultMethods.cpp/has_matching_static() helped determine this
>>> decision by looking within the current class for a static method that should be preferred during method
>>> resolution over an overpass method being created.  However, has_matching_static() did not continue to
>>> look for a static method in current class' superclasses which JDK-8033150 exposed.
>>> After looking at the code more closely, the has _matching_static() concept is being moved out out of default
>>> method processing and into method resolution processing.  The primary reason for this is to allow
>>> default method processing to match method selection where statics are and should be ignored.   According
>>> to JVMS, static methods should only be preferred over an overpass method at method and interface
>>> method resolution time.  To enable method resolution to potentially find a static method over an overpass
>>> method, a new parameter "ignore_overpass" was added to InstanceKlass::uncached_lookup_method().
>>> It has the affect of indicating to find_method_index() to ignore overpass methods and continue the search
>>> in case a static method of the same name and signature is present in the current class or its superclasses.
>>> Tests:
>>>     - jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist, JCK lang & vm, defmeth tests
>>> - Test will be added to the defmeth test system
>>> Thank you,
>>> Lois

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140411/554bded5/attachment.html>

More information about the hotspot-runtime-dev mailing list