[9] RFR (XS): C2: continuous CallSite relinkage eventually disables compilation for a method
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Mon Jan 30 21:06:40 UTC 2017
Dean,
> Are there any other uses of next_alive() where we would want something
> more strict like next_entrant()? If so then it might be worth it to add
> this to the iterator.
I briefly looked through next_alive() usages and didn't find evident
candidates.
Also, is_marked_for_deoptimization() is cheap and filters out most of
the compiled methods, so doing it first may be better.
Best regards,
Vladimir Ivanov
> On 1/30/17 5:10 AM, Vladimir Ivanov wrote:
>> Are people fine with the following version?
>>
>> http://cr.openjdk.java.net/~vlivanov/8173338/webrev.03/
>>
>> Otherwise, I'll file a separate RFE for
>> CodeCache::make_marked_nmethods_not_entrant() part.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 1/27/17 11:11 PM, Vladimir Ivanov wrote:
>>>>> I don't see how method::_code is relevant to compiled method state
>>>>> checks. It's just a double-checked locking idiom. Should be safe since
>>>>> state transitions are monotonic.
>>>>>
>>>>
>>>> I think there is a path where AOT methods can become in-use again, so
>>>> it's not completely monotonic.
>>>
>>> Ok, I can leave the pre-lock check only for nmethods.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>>> 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.
>>>>>
>>>>> I decided to keep state checks both in
>>>>> CodeCache::make_marked_nmethods_not_entrant() and
>>>>> nmethod::make_not_entrant_or_zombie(). !is_not_entrant() isn't precise
>>>>> enough, since it passes for zombie nmethods as well.
>>>>>
>>>>> Also, added equivalent pre-lock check in
>>>>> AOTCompiledMethod::make_not_entrant_helper(). Let me know if you see
>>>>> any problems with that.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>> 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