RFR (M) JDK-8033150 (#2): invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults
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:
> This includes Keith's suggestion below. All testing has been rerun successfully.
> Thank you,
> 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.
>>> - Keith
>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan <lois.foltan at oracle.com> wrote:
>>> Please review the following fix:
>>> Bug: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults
>>> 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.
>>> - 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev