2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale

[serguei.spitsyn at oracle.com]

Hi Coleen,

This is a new performance bug that targets another round of performance 
improvements per our discussion:
   https://bugs.openjdk.java.net/browse/JDK-8073705: more performance 
issues in class redefinition

Feel free to update it if necessary.


Hi Dan,

I'd be happy if you have a chance to find cycles to look at the webrev 
below.
Your opinion is always very valuable!
No time pressure, just let me know about your intention. :)


Thanks,
Serguei


On 2/20/15 6:08 PM, Coleen Phillimore wrote:
>
> Serguei,  Looks great.
>
> Thanks,
> Coleen
>
> On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote:
>> The hotspot webrev below addresses the Coleen's comments from the 
>> 1-st review round.
>>
>> Open hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ 
>>
>>
>> Open jdk (new unit test) webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ 
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>>   https://bugs.openjdk.java.net/browse/JDK-8046246
>>>
>>>
>>> Open hotspot webrevs:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ 
>>>
>>>
>>> Open jdk (new unit test) webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ 
>>>
>>>
>>>
>>> Summary:
>>>
>>>    This performance/scalability issue in class redefinition was 
>>> reported by HP and the Enterprise Manager team.
>>>    The following variants of the adjust_method_entries() functions 
>>> do not scale:
>>>      ConstantPoolCache::adjust_method_entries()
>>>      klassVtable::adjust_method_entries()
>>>      klassItable::adjust_method_entries()
>>>      InstanceKlass::adjust_default_methods()
>>>
>>>    The ConstantPoolCache::adjust_method_entries() is the most 
>>> important.
>>>
>>>    The approach is to use the holder->method_with_idnum() like this:
>>>      Method* new_method = 
>>> holder->method_with_idnum(old_method->orig_method_idnum());
>>>      if (old_method != new_method) {
>>>          <replace old_method with new_method>
>>>      }
>>>
>>>      New algorithm has effectiveness O(M) instead of original O(M^2),
>>>      where M is count of methods in the class.
>>>      The new test (see webrev above) was used to mesure CPU time 
>>> consumed by the
>>>      ConstantPoolCache::adjust_method_entries() in both original and 
>>> new approach.
>>>
>>>      The performance numbers are:
>>>
>>> --------------------------------------------------------------------------------------- 
>>>
>>>      Methods: ------ 1,000 --------------- 10,000 ----------------- 
>>> 20,000
>>> --------------------------------------------------------------------------------------- 
>>>
>>>      Orig:         600,000 nsec (1x)   60,500,000 nsec (~100x) 
>>> 243,000,000 nsec (~400x)
>>>      New:           16,000 nsec (1x)      178,000 nsec (~10x) 
>>> 355,000 nsec  (~20x)
>>> --------------------------------------------------------------------------------------- 
>>>
>>>
>>>
>>>
>>> Testing:
>>>   In progress: VM SQE RedefineClasses tests, JTREG 
>>> java/lang/instrument, com/sun/jdi tests
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>
>