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

List:       openjdk-serviceability-dev
Subject:    Re: RFR (S) 8073705: more performance issues in class redefinition
From:       Coleen Phillimore <coleen.phillimore () oracle ! com>
Date:       2015-04-28 13:58:46
Message-ID: 553F9216.6080106 () oracle ! com
[Download RAW message or body]


On 4/28/15, 12:27 AM, serguei.spitsyn@oracle.com wrote:
> On 4/27/15 1:25 PM, serguei.spitsyn@oracle.com wrote:
>> On 4/27/15 1:05 PM, serguei.spitsyn@oracle.com wrote:
>>> Hi Coleen,
>>>
>>> Thank you for the review!
>>>
>>> On 4/27/15 10:49 AM, Coleen Phillimore wrote:
>>>>
>>>> Serguei,
>>>>
>>>> This looks nice.  I thought this change was going to delay calling 
>>>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather 
>>>> than for each class, so was a bit confused by the change.
>>>
>>> I consider this for as a next round of optimizations which is more 
>>> risky.
>>> We need to decide when we are Ok to take this risk.
>>> My guess is that it is better to do it together with the constant 
>>> pool merge elimination.
>>
>> Sorry, I forgot to tell that my plan is to open another bug that should
>> cover moving all this adjustments to the end of redefinition.
>> This was a source of the confusion!
>
> I've filed a separate bug report for the above:
>   https://bugs.openjdk.java.net/browse/JDK-8078725

This is good.  I'll watch this next bug.  Yes, the optimizations are 
more risky here but I think they would still use the same code. But it 
definitely needs more testing.

Coleen

>
>
> Thanks,
> Serguei
>
>>
>> Thanks,
>> Serguei
>>
>>>
>>>>
>>>> Your change is a nice cleanup and improves MethodHandle method 
>>>> replacement performance.
>>>
>>> Thanks!
>>>
>>>>
>>>> Your backport may not be simple for jdk8 because 
>>>> PreviousVersionNode is another type and not an InstanceKlass. Maybe 
>>>> you've convinced me that it's worth backporting those changes too.  
>>>> Let me know.
>>>
>>> I've already backported the first chunk where this problem was hit.
>>> It seems, this one should not be harder to backport.
>>>
>>> Thanks!
>>> Serguei
>>>
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 4/10/15, 4:29 PM, serguei.spitsyn@oracle.com wrote:
>>>>> Hi Coleen and Dan,
>>>>>
>>>>> This is the second class redefinition scalability/optimization fix 
>>>>> that is in my queue to push into 9 and 8u60.
>>>>>
>>>>> The approach is similar to the first one but much smaller.
>>>>> For convenience, these are the links to the first scalability fix:
>>>>>      Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
>>>>>      Open webrev: 
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>>>>>
>>>>> Please, let me know if you have any chance to review this.
>>>>> This is the last one that is waiting for your attention! :)
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>> On 3/26/15 7:38 PM, serguei.spitsyn@oracle.com wrote:
>>>>>> Please, review the fix for:
>>>>>>   https://bugs.openjdk.java.net/browse/JDK-8073705
>>>>>>
>>>>>>
>>>>>> Open hotspot webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/ 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>>    This is the 2-nd round of performance/calability fixes in 
>>>>>> class redefinition.
>>>>>>    This time, the two remaining issues that were left alone in 
>>>>>> the first round fix:
>>>>>>      - optimized ConstantPoolCache::adjust_method_entries() is 
>>>>>> used for previous versions
>>>>>>      - the MemberNameTable::adjust_method_entries() has been 
>>>>>> optimized too
>>>>>>      - some cleanup
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>>   In progress: nsk redefine classes tests, JTREG 
>>>>>> java/lang/instrument, com/sun/jdi
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>
>>>>
>>>
>>
>

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