RFR: 8214257: IC cache not clean after cleaning assertion failure

Erik Österlund erik.osterlund at oracle.com
Mon Dec 3 15:35:39 UTC 2018


Hi Vladimir,

Thanks for the review.

/Erik

On 2018-11-28 19:25, Vladimir Kozlov wrote:
> Looks good to me.
> 
> Thanks,
> Vladimir
> 
> On 11/27/18 5:00 AM, Erik Österlund wrote:
>> Hi,
>>
>> Back in 8212681, an abstract CompiledICLocker was introduce to protect 
>> inline caches from concurrent patching.
>>
>> Unfortunately, not all patching of ICs started using the 
>> CompiledICLocker. There were still some callsites using the 
>> Patching_lock. Therefore, the assert may trigger sometimes saying the 
>> IC cache is not clean right after cleaning, due to other concurrent 
>> modifications under the Patching_lock.
>>
>> Also, in CompiledIC::set_to_clean(), the condition for safe_transition 
>> was altered incorrectly from is_at_safepoint() to 
>> CompiledICLocker::is_safe(), causing cleaning to not used transition, 
>> so I reinstated that in this patch.
>>
>> This patch depends on 8214338 by assuming that the CompiledICLocker 
>> does not use safepoint checks, as it is now used from leaf calls where 
>> safepointing is not allowed.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8214257
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8214257/webrev.00/
>>
>> Thanks,
>> /Erik


More information about the hotspot-dev mailing list