RFR (M) JDK-8033150 (#2): invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults
lois.foltan at oracle.com
Fri Apr 11 14:07:11 UTC 2014
On 4/11/2014 9:51 AM, Keith McGuigan wrote:
> Hi Lois,
> Looks good, thanks for making that change!
Thank you Keith for reviewing.
> - Keith
> On Fri, Apr 11, 2014 at 9:04 AM, Lois Foltan <lois.foltan at oracle.com
> <mailto:lois.foltan at oracle.com>> 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 <mailto: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
>>> 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