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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Mon Mar 10 23:57:35 UTC 2014

Vladimir, thanks for the review.

You are absolutely right about 
Method::increment_interpreter_invocation_count. Reverted the change.

Updated fix:

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

More information about the hotspot-compiler-dev mailing list