RFR (XXS): 8023461: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
vladimir.kozlov at oracle.com
Tue May 13 23:24:54 UTC 2014
On 5/13/14 4:23 PM, Vladimir Ivanov wrote:
> Vladimir, thanks!
> On 5/14/14 2:58 AM, Vladimir Kozlov wrote:
>> On 5/13/14 2:34 PM, Vladimir Ivanov wrote:
>>>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>>>> exclude safepoints in it.
>>> OK. I planned to fix select_task separately (filed RFE to track that),
>>> since people complains about intermittent failures during testing due to
>>> this bug and I have some concerns with the fix I had. But I'll try to
>>> fix it as part of this change then.
>>>> The update_rate() could be not called if there are no MethodCounters
>>>> (other places may need to be fixed for that). Actually I don't
>>>> understand how we have compilation request for a method without
>>>> MethodCounters. Counters should be created before that.
>>> It's not always the case. MDO can be created first (e.g. compilation can
>>> force MDO creation ) and there's no need in MethodCounters (see
>>> InterpreterGenerator::generate_counter_incr ).
>> I think this is contradiction in tiered implementation. We don't
>> allocate MethodCounters for TieredCompilation as you pointed but tiered
>> code uses them.
> I agree. Filed JDK-8043061 to track that.
>>>> And removing stale tasks could be done in an other place, outside MCQ
>>> I looked again closely at the code and I think I found a sweet spot.
>>> Updated webrev:
>> Very good. Add small comment explaining your trick to avoid conflicts
>> with other compiler threads after lock is released:
>> + CompileTask* head = _first_stale;
>> + _first_stale = NULL;
> Updated webrev in place with a comment:
> Best regards,
> Vladimir Ivanov
>  https://bugs.openjdk.java.net/browse/JDK-8043061
More information about the hotspot-compiler-dev