Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Jan 31 06:32:11 PST 2012
Sorry, sent that last one as "reply to list" instead of "reply to all"...
I think you need to hold up on this one. I don't think the
assumption that .java_pid and .attach_pid files are always
in /tmp is a good one.
More in a little bit.
Dan
On 1/31/12 1:10 AM, Staffan Larsen wrote:
> Moving "/tmp" to a static field, made it easier to write a comment
> explaining the rationale as well.
>
> Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/
> <http://cr.openjdk.java.net/%7Esla/7132199/webrev.02/>
>
> Thanks,
> /Staffan
>
> On 31 jan 2012, at 01:23, David Holmes wrote:
>
>> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote:
>>> On 2012-01-30 16:28, Staffan Larsen wrote:
>>>>> 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.
>>
>> Staffan: I still think changing the static field tmpdir to refer to
>> "/tmp" is cleaner then putting "/tmp" in all the use-sites.
>>
>>> /tmp is common but not mandatory, especially if we speak about embedded
>>> systems.
>>
>> Dmitry: The point is that the VM will always put the file in /tmp.
>> That's wrong but the issue here is making the management Java code
>> match the hotspot code.
>>
>>> Native code should use P_tmpdir constant from stdio.h rather than
>>> hardcode "/tmp".
>>>
>>> As we can't access it from java I recommend to create a global constant
>>> somewhere to reduce possible future porting efforts.
>>>
>>>
>>>> Changing the tmpdir static would be a smaller fix, but all the cwd code
>>>> would then remain. Yes, HotSpot never writes to cwd.
>>>
>>> I agree with Staffan, that looks for socket/door in cwd should be
>>> removed.
>>
>> Ok, if it is never needed then remove it.
>>
>> David
>>
>>> -Dmitry
>>>
>
More information about the serviceability-dev
mailing list