Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms

[Staffan Larsen]

On 30 jan 2012, at 12:23, Dmitry Samersoff wrote:

> 1. Why we can't use System.getProperty("java.io.tmpdir") ?

Since HotSpot and the tools run in separate processes it is important that the file is in a well-known global location. It cannot be in different locations for different processes. Since java.io.tmpdir can be set on the command line (which JPRT does), it can be different in the tools and in HotSpot.  

HotSpot will always write the file to /tmp/.java_pidXXX regardless of the value of java.io.tmpdir (see 7009828). Thus, the tools need to always look there.

> 2. If you decide to hardcode "/tmp" please, create a global constant for it.

I don't agree that this would make the code easier to read or maintain. I should, however, include a comment saying that the file is always in /tmp regardless of the value of java.io.tmpdir.


On 30 jan 2012, at 12:49, David Holmes wrote:

> I'm somewhat confused by this problem. 6938627 is the CR that changed from /tmp to use the java.io.tmpdir property, but that CR did not modify the files that you have modified - so what broke these files?

7009828 then changed HotSpot back to use /tmp always. I seems like this has been going back and forth for a while… I don't really know the whole history.

> Looking at your fix, wouldn't it be simpler to just set the static tmpdir to /tmp and leave the rest of the code as-is? Why do you stop looking in the cwd in addition to changing the tmp location? Is it because hotspot will never write it there?

Changing the tmpdir static would be a smaller fix, but all the cwd code would then remain. Yes, HotSpot never writes to cwd.

Thanks,
/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120130/555d8fcd/attachment.html