RFR (S): 8023461: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock

[Vladimir Ivanov]

Unfortunately, it's not enough. There's another safepoint check.

For blocking compilation requests of stale methods CompileTaskWrapper 
(see AdvancedThresholdPolicy::select_task) sends a notification to 
blocked threads after cancelling the compilation. It can safepoint while 
locking on compile task before sending notification.

I don't see how to avoid this situation. Any ideas?
Otherwise, I need to exclude MethodCompileQueue from the check in 
Thread::check_for_valid_safepoint_state.

Best regards,
Vladimir Ivanov

On 3/11/14 11:58 AM, Vladimir Ivanov wrote:
> Igor, Vladimir, thanks for review.
>
> Best regards,
> Vladimir Ivanov
>
> On 3/11/14 7:31 AM, Igor Veresov wrote:
>> I think it’s a reasonable fix.
>>
>> igor
>>
>> On Mar 10, 2014, at 4:57 PM, Vladimir Ivanov
>> <vladimir.x.ivanov at oracle.com> wrote:
>>
>>> Vladimir, thanks for the review.
>>>
>>> You are absolutely right about
>>> Method::increment_interpreter_invocation_count. Reverted the change.
>>>
>>> Updated fix:
>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.01/
>>>
>>> Yes, Igor's feedback on this change would be invaluable.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 3/11/14 2:33 AM, Vladimir Kozlov wrote:
>>>> The method Method::increment_interpreter_invocation_count(TRAP) changes
>>>> are incorrect. It is used by C++ Interpreter and you did not modified
>>>> code there. I would leave this method unchanged.
>>>>
>>>> The rest looks fine to me but Igor should know better this code.
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> On 3/7/14 8:26 AM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.00
>>>>> https://bugs.openjdk.java.net/browse/JDK-8023461
>>>>> 42 lines changed: 13 ins; 1 del; 28 mod
>>>>>
>>>>> The rule of thumb for VM is that a thread shouldn't hold any VM lock
>>>>> when it reaches a safepoint. It's not the case for
>>>>> MethodCompileQueue_lock now.
>>>>>
>>>>> The problem is that AdvancedThresholdPolicy updates task's rate when
>>>>> iterating compiler queue. It holds MethodCompileQueue_lock while doing
>>>>> so. Method counters are allocated lazily. If method counters aren't
>>>>> there and VM fails to allocate them, GC is initiated (see
>>>>> CollectorPolicy::satisfy_failed_metadata_allocation) and a thead
>>>>> entering a safepoint holding MethodCompileQueue lock.
>>>>>
>>>>> Normally, counters are initialized during method interpretation,
>>>>> but in
>>>>> Xcomp mode it's not the case. That's the mode where the failures are
>>>>> observed.
>>>>>
>>>>> The fix is to skip the update, if counters aren't allocated yet.
>>>>>
>>>>> Testing: added No_Safepoint_Verifier, JPRT, failing tests from nightly
>>>>> testing (in progress).
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>