RFR(S): 8063112: Compiler diagnostic commands should have locking instead of safepoint

Nils Eliasson nils.eliasson at oracle.com
Mon Nov 10 10:38:01 UTC 2014

Hi Albert,

On 2014-11-10 11:10, Albert Noll wrote:
> Hi Nils,
> On 11/06/2014 02:22 PM, Nils Eliasson wrote:
>> Hi,
>> Please review this small change.
>> The first implementation of compiler diagnostic commands was 
>> asserting on safepoint or lock. The safepoint was always taken since 
>> the dcmd by default block for a safepoint. That is not correct, the 
>> lock must be taken, and a whether we are at a safepoint doesn't matter.
> Could you please explain why we always need to take the lock?

Mutation of the code cache can happen at any time, for example when a 
new compiled method is installed. The codelist dcmd iterates the code 
cache and might see a dangling pointer. The code cache stats dcmd only 
print statisticss, so it won't break but can see bad data.


> Thanks,
> Albert
>> Tested with jtreg tests in Hotspot and JDK that exercise this code.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8063112
>> Webrev: http://cr.openjdk.java.net/~neliasso/8063112/webrev.01/
>> Thanks,
>> Nils

More information about the hotspot-compiler-dev mailing list