RFR(S): 8063112: Compiler diagnostic commands should have locking instead of safepoint
nils.eliasson at oracle.com
Mon Nov 10 10:38:01 UTC 2014
On 2014-11-10 11:10, Albert Noll wrote:
> Hi Nils,
> On 11/06/2014 02:22 PM, Nils Eliasson wrote:
>> 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.
>> 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/
More information about the hotspot-compiler-dev