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

Tom Rodriguez tom.rodriguez at oracle.com
Tue Dec 10 09:24:10 UTC 2019



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.

> 
> 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.

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


More information about the hotspot-compiler-dev mailing list