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

[Vladimir Kozlov]

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