[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR (S) JDK-8067480: Crash in klassItable::initialize_itable_for_interface
From:       Lois Foltan <lois.foltan () oracle ! com>
Date:       2015-01-21 16:57:06
Message-ID: 54BFDA62.2060708 () oracle ! com
[Download RAW message or body]

Thank you Karen and Harold for the review!
Lois

On 1/21/2015 11:36 AM, Karen Kinnear wrote:
> Looks good. Many thanks.
>
> Karen
>
> On Jan 19, 2015, at 4:11 PM, Lois Foltan wrote:
>
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~lfoltan/bug_jdk8067480/
>>
>> Bug: Crash in klassItable::initialize_itable_for_interface when runnin=
g vm.runtime.defmeth.StaticMethodsTest on Linux x64
>>     https://bugs.openjdk.java.net/browse/JDK-8067480
>>
>> Summary:
>> The previous fix for JDK-8033150: (invokestatic: IncompatibleClassChan=
geError trying to invoke static method from a parent in presence of confl=
icting defaults), made the change to include overpass methods in a class'=
 local method array even when a static method is present.  An overpass me=
thod is added to the current class' local method array for issues that ha=
ve been encountered during the walk of the default methods.  This fix all=
owed default method processing to match method selection where statics ar=
e and should be ignored. To have the static methods then later be preferr=
ed over an overpass method at method and interface method resolution time=
, the fix for JDK-8033150 introduced the concept of "skipping_overpass" d=
uring method lookup.
>>
>> The current bug, JDK-8067480, exposes a problem with allowing both a s=
tatic method and an overpass method that share the same method name and s=
ignature to co-exist in a class' local method array.  A class' local meth=
od array is ordered based on the method name's Symbol* address.  So depen=
ding on this ordering, which happened to start differing between a fastde=
bug and product build, instanceKlass::find_instance_method() was returnin=
g NULL because the static method was found first and searching did not co=
ntinue to find the overpass method of the same name and signature.  This =
led to consequences downstream when decisions were being made as to whith=
er or not a miranda method should be added during the class' vtable initi=
alization.  During a fastdebug build, find_instance_method() found the ov=
erpass method and vtable initialization ended correctly.  During a produc=
t build, due to a differing sorted order of the class' method array, the =
static method was found which caused the vtable initialization to determi=
ne a miranda method was needed, overrunning the vtable and actually overw=
riting the first slot in the itable.  instanceKlass::find_instance_method=
() must have the concept added of "skipping_statics", must like the "skip=
ping_overpass" concept.  It should skip a static method of the same name =
and signature and instead of stopping, keep searching in case an overpass=
 method of the same name and signature exists as well.
>>
>> Tests:
>>    defmeth, java/lang, java/util, hotspot jtreg - completed
>>    vm.quick.testlist - in progress


[prev in list] [next in list] [prev in thread] [next in thread]