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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Mar 7 16:26:45 UTC 2014


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