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

[Vladimir Kozlov]

On 12/10/19 1:24 AM, Tom Rodriguez wrote:
> 
> 
> Vladimir Kozlov wrote on 12/9/19 8:09 PM:
>> But it looks like there are testing failures.
> 
> None of the testing failures look like they have anything to do with 
> these changes.  They all have failed recently in other builds from what 
> I can see.

You are right. I was concern about 2 kitchensink failures but they are 
present in current code too based on failure history.

> 
>>
>> The idea and changes seems fine to me. The only question I have is why 
>> JVMCI code want to deoptimize all related compiler frames immediately? 
>> Why marking is not enough?
> 
> I'm not sure what you're asking.  mark_for_deoptimization doesn't really 
> do anything on it's own.  You have to do the code cache scan to 
> make_not_entrant and then do the stack walks to invalidate any frames 
> which are still using that code.  I'm not changing the semantic of the 
> original function either, just skipping a useless full code cache scan.

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)?

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