RFR (XXS): 8023461: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
vladimir.x.ivanov at oracle.com
Tue May 13 22:33:38 UTC 2014
> I think that’s reasonable. Thanks for pointing out the fact the we can have an MDO and no MC with, say, Xcomp and tiered. With your check in update_rate() we’ll no longer force their allocation. I’ll have add their allocation explicitly to the code aging code for that case.
Not necessarily -Xcomp + Tiered. There are rare cases in normal mode as
> Indent in remove_and_mark_stale() is off.
> On May 13, 2014, at 2:34 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>>> exclude safepoints in it.
>> OK. I planned to fix select_task separately (filed RFE to track that), since people complains about intermittent failures during testing due to this bug and I have some concerns with the fix I had. But I'll try to fix it as part of this change then.
>>> The update_rate() could be not called if there are no MethodCounters
>>> (other places may need to be fixed for that). Actually I don't
>>> understand how we have compilation request for a method without
>>> MethodCounters. Counters should be created before that.
>> It's not always the case. MDO can be created first (e.g. compilation can force MDO creation ) and there's no need in MethodCounters (see InterpreterGenerator::generate_counter_incr ).
>>> And removing stale tasks could be done in an other place, outside MCQ lock.
>> I looked again closely at the code and I think I found a sweet spot.
>> Updated webrev:
>> Testing: JPRT, VM testbase, bigapps, jtreg
>> Best regards,
>> Vladimir Ivanov
>> Method::build_interpreter_method_data(methodHandle, Thread*)
>> GraphBuilder::try_inline_full(ciMethod*, bool, Bytecodes::Code, Instruction*)
>>  http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/cpu/x86/vm/templateInterpreter_x86_32.cpp#l340
>>> Vladimir K
>>> On 5/12/14 11:15 AM, Vladimir Ivanov wrote:
>>>> CompileQueue::get() acquires MethodCompileQueue lock before extracting a
>>>> task from the compilation queue. In Tiered mode it calls
>>>> AdvancedThresholdPolicy::select_task, which can safepoint in multiple
>>>> places. It fires an assert which checks there are no VM locks held VM
>>>> thread can block on.
>>>> I checked the code and didn't find any scenarios where VM acquires MCQ
>>>> lock and submits a compilation task from a safepoint, so I decided to
>>>> relax the assert in Thread::check_for_valid_safepoint_state for now and
>>>> exclude MethodCompileQueue in Tiered mode from the check.
>>>> I tried to rewrite ATP::select_task to avoid safepoints, but didn't
>>>> succeed. I filed a RFE to further investigate that path (JDK-8042925
>>>> : Consider avoiding safepoints in ...::select_task). Eventually I
>>>> want ATP::select_task to become safepoint-free and then strengthen the
>>>> check back.
>>>> For the problems spotted during analysis, I filed 2 followup bugs:
>>>>  JDK-8042924: Possible memory leak during MethodCounters
>>>>  JDK-8042926: AdvancedThresholdPolicy::update_rate should use
>>>> handles for Method*
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>  https://bugs.openjdk.java.net/browse/JDK-8042924
>>>>  https://bugs.openjdk.java.net/browse/JDK-8042926
>>>>  https://bugs.openjdk.java.net/browse/JDK-8042925
More information about the hotspot-compiler-dev