RFR(S) 8229377: [JVMCI] Improve InstalledCode.invalidate for large code caches

[Tom Rodriguez]

http://cr.openjdk.java.net/~never/8229377.1/webrev/

I have moved all the logic over into deoptimize_all_marked and added 
some comments to the method.  I also rearranged the invalidation logic 
to make it cleaner.  I've submitted the new version for testing.

tom

Tom Rodriguez wrote on 12/10/19 11:21 PM:
>> Yes, right. I am confusing because not in all places we do this 
>> sequence: mark_for_deoptimization, make_not_entrant, patch frames.
>> Patching frames are not always at the same place as we do marking.
>>
>> I also noticed that you changed under which locks make_not_entrant is 
>> done. May be better to pass nmethod into deoptimize_all_marked() and 
>> do it there (by default pass NULL)?
> 
> You mean the CodeCache_lock?  The CompiledMethod_lock is only thing 
> required for make_not_entrant and that's acquired in 
> make_not_entrant_or_zombie.  The CodeCache_lock is required for the safe 
> iteration over the CodeCache itself.
> 
> Though I kind of like your suggestion of passing the nmethod to the call 
> and performing the make_not_entrant call there instead.  It keeps the 
> logic together.  I'll make that change.
> 
> tom
> 
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> tom
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 12/9/19 12:10 PM, Tom Rodriguez wrote:
>>>>> http://cr.openjdk.java.net/~never/8229377/webrev
>>>>> https://bugs.openjdk.java.net/browse/JDK-8229377
>>>>>
>>>>> This is a minor improvement to the JVMCI invalidate method to avoid 
>>>>> scanning large code caches when invalidating a single nmethod. 
>>>>> Instead the nmethod is directly made not_entrant.  In general I'm 
>>>>> unclear what the benefit of the 
>>>>> mark_for_deoptimization/make_marked_nmethods_not_entrant split is. 
>>>>> Testing is in progress.
>>>>>
>>>>> JDK-8230884 had been previously duplicated against this because 
>>>>> they overlapped a bit, but in the interest of clarity I separated 
>>>>> them again.
>>>>>
>>>>> tom