RFR (S): 8023461: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
igor.veresov at oracle.com
Tue Mar 11 03:31:36 UTC 2014
I think it’s a reasonable fix.
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:
> 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.
>> Vladimir K
>> On 3/7/14 8:26 AM, Vladimir Ivanov wrote:
>>> 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
>>> 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