RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Tue Feb 5 13:52:13 UTC 2019


Yes, I can do that.  Thank you for reviewing this!
Coleen

On 2/5/19 1:50 AM, dean.long at oracle.com wrote:
> Could you move this code:
>
>      // Mark dependent AOT nmethods, which are only found via the 
> class redefined.
>      AOTLoader::mark_evol_dependent_methods(ik);
>
> into this function:
>
>      CodeCache::mark_for_evol_deoptimization(ik)
>
> The rest looks good.
>
> dl
>
> On 2/4/19 7:08 AM, coleen.phillimore at oracle.com wrote:
>> Summary: Walk code cache and deoptimize once per redefinition.*
>>
>> *This change touches the AOT and code cache code.  I tried to 
>> describe it in the comments in the RFE.  Basically, for redefinition, 
>> we walk the code cache per class redefined in order to find 
>> evol_method dependencies, then deoptimize if we find them, and then 
>> walk the code cache again to mark the deoptimized nmethods as 
>> not_entrant.
>>
>> I replaced this with only marking any nmethods for the class's 
>> methods to deoptimize (following InstanceKlass::_methods), also 
>> marking aot methods dependent on the class, and then doing the code 
>> cache walk to follow the evol_method dependencies at the end of 
>> redefinition for all the classes.   The new code uses the 
>> Method::is_old() flag rather than comparing each method in the 
>> InstanceKlass.  Then deoptimization and marking not_entrant is done 
>> once at the end of the redefinition as well.
>>
>> Tested with tier1-6, all the redefinition tests locally:
>>
>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out
>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out
>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests 
>> >&redefine.out
>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out
>>
>> new test, and JMH test (see CR for results).
>>
>> Thanks,
>> Coleen
>>
>>
>



More information about the serviceability-dev mailing list