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

[Tom Rodriguez]

> 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