RFR(t) 8217424 Remove the idempotent parameter to Method::sort_methods

[coleen.phillimore at oracle.com]

On 1/22/19 2:40 PM, Ioi Lam wrote:
> Hi Coleen, thanks for the archeological report. I can't really 
> understand what this comment means, either.
>
> Also thanks to Aleksey for the review. I'll push the changeset now.
>
> BTW, I wonder why we don't do a complete ordering using the method 
> name + signature. That way we can do a simple binary search, and 
> there's no need for the up and down walking in 
> InstanceKlass::find_method_index.

I don't know either.  It would help with redefinition in checking for 
matching methods.

Coleen
>
> Thanks
>
> - Ioi
>
> On 1/22/19 5:33 AM, coleen.phillimore at oracle.com wrote:
>>
>> I checked out of curiousity, this is what it used to do:
>>
>>   // Prevent qsort from reordering a previous valid sort by
>>   // considering the address of the methodOops if two methods
>>   // would otherwise compare as equal.  Required to preserve
>>   // optimal access order in the shared archive.  Slower than
>>   // method_compare, only used for shared archive creation.
>>   static int method_compare_idempotent(methodOop* a, methodOop* b) {
>>     int i = method_compare(a, b);
>>     if (i != 0) return i;
>>     return ( a < b ? -1 : (a == b ? 0 : 1));
>>   }
>>
>> So if the Method name was the same it would preserve the order in the 
>> CDS archive.  Not sure why that would have been optimial.
>> Looks good!
>> Coleen
>>
>> On 1/22/19 12:30 AM, Ioi Lam wrote:
>>> Please review this trivial change.
>>>
>>> The "idempotent" parameter to Method::sort_methods() is always 
>>> false, so let's just remove it.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8217424
>>> http://cr.openjdk.java.net/~iklam/jdk13/8217424-sort-methods-idempotent-param.v01/ 
>>>
>>>
>>> Thanks
>>> - Ioi
>>