[9] RFR (XS): C2: continuous CallSite relinkage eventually disables compilation for a method
dean.long at oracle.com
dean.long at oracle.com
Mon Jan 30 21:32:41 UTC 2017
On 1/30/17 1:06 PM, Vladimir Ivanov wrote:
> 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.
>
OK, then webrev.03 looks good to me.
dl
> 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