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