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

[Vladimir Kozlov]

Nice.

Thanks,
Vladimir

On 12/11/19 12:17 PM, Tom Rodriguez wrote:
> 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