[9] RFR (XS): C2: continuous CallSite relinkage eventually disables compilation for a method

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Jan 26 23:19:18 UTC 2017


On 1/26/17 3:06 PM, Vladimir Kozlov wrote:
> It could be unsafe to check outside lock. method::_code is cleaned up under the same lock but after the state change. So
> if a caller access _code field it would be wrong.
>
> But, I think, it should be safe with your original change in CodeCache::make_marked_nmethods_not_entrant() because it
> does not access method::_code. You should use !is_not_entrant() instead of is_alive() - it works for AOT too.

"instead of is_in_use()"

>
> Thanks,
> Vladimir K
>
> On 1/26/17 12:44 PM, Vladimir Ivanov wrote:
>> What about moving the check to nmethod::make_not_entrant()?
>>
>> http://cr.openjdk.java.net/~vlivanov/8173338/webrev.01
>>
>> Or I can fix it separately.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 1/26/17 11:30 PM, Vladimir Kozlov wrote:
>>> It will not work for AOT nmethods which have not_used state.
>>>
>>> Vladimir
>>>
>>> On 1/26/17 8:47 AM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8173338/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8173338
>>>>
>>>> The fix for JDK-7177745 disabled deoptimization count update when it
>>>> happens due to CallSite.target change.
>>>>
>>>> There was one case missed though: the count is still updated when
>>>> compilation fails due to a dependency becoming invalid
>>>> during the compilation.
>>>>
>>>> The fix is to avoid the update when recompilation fails due to
>>>> call_site_target dependency failure.
>>>>
>>>> Also, added a check in CodeCache::make_marked_nmethods_not_entrant()
>>>> to avoid repeated nmethod::make_not_entrant() calls
>>>> on nmethods which are already not entrant. Otherwise, the check is
>>>> performed under Patching_lock inside
>>>> nmethod::make_not_entrant_or_zombie() for every non-entrant method in
>>>> the code cache.
>>>>
>>>> Testing: regression test, RBT (in progress)
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov


More information about the hotspot-compiler-dev mailing list