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.

Regards,
Nils

>
> 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