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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Mon May 12 18:15:03 UTC 2014


http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8023461

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 
[3]: 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:
   [1] JDK-8042924: Possible memory leak during MethodCounters 
initialization
   [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use 
handles for Method*

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8042924
[2] https://bugs.openjdk.java.net/browse/JDK-8042926
[3] https://bugs.openjdk.java.net/browse/JDK-8042925


More information about the hotspot-runtime-dev mailing list