RFR(S): 8061256: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java timed out

Albert Noll albert.noll at oracle.com
Thu Nov 13 15:36:35 UTC 2014

Hi Nils,

On 11/13/2014 03:58 PM, Albert Noll wrote:
> Hi Nils,
> CompileQueue::lock() always returns MethodCompileQueue_lock ( see 
> init_compiler_sweeper_threads() ). It seems that your changes don't 
> change existing behavior, or am I missing something? Note that we have 
> 2 compilation queues, but only 1 lock.
It seems that I missed the most important parts of you change indeed. Is 
it right that

Mode evaluation_mode() const { return _no_safepoint; }

makes the VM operation not execute at a safepoint? I have a question 
nevertheless. Why did you choose to return '_no_safepoint'  and not 


> On 11/13/2014 03:11 PM, Nils Eliasson wrote:
>> Hi,
>> Please review this small change.
>> 1) Fixing a deadlock in diagnostic command dcmd print_compile_queues 
>> - between the CompileQueue_lock and safepointing. The 
>> CompileQueue_lock requires that we are not at a safepoint when taking 
>> it. Otherwise a java-thread that already holds the lock will block 
>> when trying to get another lock. In this specific case the compiler 
>> threads are Java threads, they take the CompileQueue_lock frequently 
>> and some time takes the CompileTaskAlloc_lock after that.
>> Fixing this by making the diagnostic command not request a safepoint,
>> 2) Refactoring away the lock() accessor in CompileQueue and stating 
>> the lock explicitly. This removes an element of surprise and makes it 
>> easier understanding the code.
> What element of surprise are you talking about? Personally, I prefer 
> the current design, i.e., getting the lock by calling a function 
> instead of referencing a global variable directly. If we ever decide 
> to go for a 2 compile queue locks (I think that makes sense since we 
> have two compilation queues), we would have to introduce the functions 
> again.
> Best,
> Albert
>> webrev: http://cr.openjdk.java.net/~neliasso/8061256/webrev.02/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8061256
>> Thanks,
>> Nils Eliasson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141113/3b5aaf63/attachment.html>

More information about the hotspot-compiler-dev mailing list