[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
From: "Daniel D. Daugherty" <daniel.daugherty () oracle ! com>
Date: 2014-04-25 15:23:51
Message-ID: 535A7E07.1090206 () oracle ! com
[Download RAW message or body]
Looks like when the bug was filed Oracle internal information like
hostnames were included in the description section. You can edit
it out, but that doesn't remove it from the history so the entire
bug has to be marked confidential...
We've updated our internal wikis to let folks know that they should
put non-Oracle-internal info in the description and then add a separate
note for the configuration info with the access level set to "screening
required" or "confidential". Getting everyone on the same page is slow
process...
Dan
On 4/25/14 9:16 AM, Staffan Larsen wrote:
> Thanks Keith!
>
> As far as I can tell there was no good reason for making the bug
> Confidential, but I can’t undo it. Sorry about that.
>
> /Staffan
>
> On 25 apr 2014, at 17:02, Keith McGuigan <kmcguigan@twitter.com
> <mailto:kmcguigan@twitter.com>> wrote:
>
>> Hi Staffan -
>>
>> It looks good to me. Why is the bug marked "closed" though?
>>
>>
>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen
>> <staffan.larsen@oracle.com <mailto:staffan.larsen@oracle.com>> wrote:
>>
>> Still looking for a Review of this change.
>>
>> Thanks,
>> /Staffan
>>
>> On 7 apr 2014, at 21:19, Staffan Larsen
>> <staffan.larsen@oracle.com <mailto:staffan.larsen@oracle.com>> wrote:
>>
>> > And the links:
>> >
>> > bug: https://bugs.openjdk.java.net/browse/JDK-8033104
>> > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/
>> <http://cr.openjdk.java.net/%7Esla/8033104/webrev.00/>
>> >
>> > Sorry about that,
>> > /Staffan
>> >
>> > On 7 apr 2014, at 20:08, Staffan Larsen
>> <staffan.larsen@oracle.com <mailto:staffan.larsen@oracle.com>> wrote:
>> >
>> >>
>> >> The problem here is that the code for finding local VMs is not
>> looking for the data in the correct place.
>> >>
>> >> When a JVM is started it will create the perf-data file in a
>> user-specific directory inside /tmp (*). The code in the JDK
>> (PerfDataFile.java) that lists all active JVMs looks for the
>> user-specific directory inside java.io.tmpdir. If a user sets
>> -Djava.io.tmpdir on the command line, the code in PerfDataFile
>> will look in the wrong place.
>> >>
>> >> (*) It's a little bit more complex. /tmp is used on Linux and
>> Solaris. On OS X and Windows, there are user-specific temp
>> directories that should be used, and so the VM queries the OS for
>> these paths.
>> >>
>> >> The solution would be for PerfDataFile to use the same
>> locations as the VM creates them in. The simplest way to
>> guarantee that the same directory is used is to ask the VM to
>> provide the location. Thus I have introduced a new JVM_ function:
>> JVM_GetTemporaryDirectory.
>> >>
>> >> (Since this change touches both hotspot and jdk repos I will
>> submit the hotspot part first under a different bug id (provided
>> that the review goes well)).
>> >>
>> >> The newly added test starts two VM with all possible
>> combinations of setting and not setting java.io.tmpdir to verify
>> that the mechanism is indeed not looking at that variable. I also
>> removed an if-statement in BasicTests.java which would have found
>> this issue a long time ago had it not been there.
>> >>
>> >> Thanks,
>> >> /Staffan
>> >
>>
>>
>>
>>
>> --
>> twitter-icon-large.png
>>
>> Keith McGuigan
>> @kamggg
>> kmcguigan@twitter.com <mailto:kmcguigan@twitter.com>
>>
>
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Looks like when the bug was filed Oracle internal information
like<br>
hostnames were included in the description section. You can edit<br>
it out, but that doesn't remove it from the history so the entire<br>
bug has to be marked confidential...<br>
<br>
We've updated our internal wikis to let folks know that they
should<br>
put non-Oracle-internal info in the description and then add a
separate<br>
note for the configuration info with the access level set to
"screening<br>
required" or "confidential". Getting everyone on the same page is
slow<br>
process...<br>
<br>
Dan<br>
<br>
<br>
</tt>
<div class="moz-cite-prefix">On 4/25/14 9:16 AM, Staffan Larsen
wrote:<br>
</div>
<blockquote
cite="mid:006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Thanks Keith!
<div><br>
</div>
<div>As far as I can tell there was no good reason for making the
bug Confidential, but I can’t undo it. Sorry about that.</div>
<div><br>
</div>
<div>/Staffan</div>
<div><br>
<div>
<div>On 25 apr 2014, at 17:02, Keith McGuigan <<a
moz-do-not-send="true" \
href="mailto:kmcguigan@twitter.com">kmcguigan@twitter.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Hi Staffan -
<div><br>
</div>
<div>It looks good to me. Why is the bug marked "closed"
though?</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Apr 25, 2014 at 8:56
AM, Staffan Larsen <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:staffan.larsen@oracle.com"
target="_blank">staffan.larsen@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Still
looking for a Review of this change.<br>
<br>
Thanks,<br>
/Staffan<br>
<br>
On 7 apr 2014, at 21:19, Staffan Larsen <<a
moz-do-not-send="true"
\
href="mailto:staffan.larsen@oracle.com">staffan.larsen@oracle.com</a>> wrote:<br>
<br>
> And the links:<br>
><br>
> bug: <a moz-do-not-send="true"
href="https://bugs.openjdk.java.net/browse/JDK-8033104"
\
target="_blank">https://bugs.openjdk.java.net/browse/JDK-8033104</a><br> > \
webrev: <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Esla/8033104/webrev.00/"
\
target="_blank">http://cr.openjdk.java.net/~sla/8033104/webrev.00/</a><br> ><br>
> Sorry about that,<br>
> /Staffan<br>
><br>
> On 7 apr 2014, at 20:08, Staffan Larsen <<a
moz-do-not-send="true"
\
href="mailto:staffan.larsen@oracle.com">staffan.larsen@oracle.com</a>> wrote:<br>
><br>
>><br>
>> The problem here is that the code for
finding local VMs is not looking for the data in the
correct place.<br>
>><br>
>> When a JVM is started it will create the
perf-data file in a user-specific directory inside
/tmp (*). The code in the JDK (PerfDataFile.java)
that lists all active JVMs looks for the
user-specific directory inside java.io.tmpdir. If a
user sets -Djava.io.tmpdir on the command line, the
code in PerfDataFile will look in the wrong place.<br>
>><br>
>> (*) It's a little bit more complex. /tmp is
used on Linux and Solaris. On OS X and Windows,
there are user-specific temp directories that should
be used, and so the VM queries the OS for these
paths.<br>
>><br>
>> The solution would be for PerfDataFile to
use the same locations as the VM creates them in.
The simplest way to guarantee that the same
directory is used is to ask the VM to provide the
location. Thus I have introduced a new JVM_
function: JVM_GetTemporaryDirectory.<br>
>><br>
>> (Since this change touches both hotspot and
jdk repos I will submit the hotspot part first under
a different bug id (provided that the review goes
well)).<br>
>><br>
>> The newly added test starts two VM with all
possible combinations of setting and not setting
java.io.tmpdir to verify that the mechanism is
indeed not looking at that variable. I also removed
an if-statement in BasicTests.java which would have
found this issue a long time ago had it not been
there.<br>
>><br>
>> Thanks,<br>
>> /Staffan<br>
><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"><span
id="docs-internal-guid-6d35c17c-9421-7cb3-ede8-7846b53edbbc">
<div dir="ltr" style="margin-left:0pt">
<table
style="border:none;border-collapse:collapse">
<colgroup><col width="48"><col width="161"></colgroup><tbody>
<tr style="height:0px">
<td style="border-left:solid #000000
0px;border-right:solid #000000
0px;border-bottom:solid #000000
0px;border-top:solid #000000
0px;vertical-align:top;padding:7px 7px 7px
7px">
<div style="text-align: center;
line-height: 1; margin-top: 0pt;
margin-bottom: 0pt;"><img
moz-do-not-send="true"
src="https://lh5.googleusercontent.com/u6Xn6JDdNN6CNxcDBUqgX0FAbqisyuZDFvP4pAPPuTE6lFi \
z5D3t6_VfDUcwR7TyF6ylFgzbJzj6xQ1FzJq9eqzchQouhQW-hkiRR9woyZ9BxZzJev76dh5S3B_8VIcQJA" \
style="border: none; transform: rotate(0.00rad); -webkit-transform:
rotate(0.00rad);"
alt="twitter-icon-large.png"
height="32px;" width="33px;"><span
style="font-size: 15px; font-family:
Arial; background-color: transparent;
vertical-align: baseline; white-space:
pre-wrap;"></span></div>
</td>
<td style="border-left:solid #000000
0px;border-right:solid #000000
0px;border-bottom:solid #000000
0px;border-top:solid #000000
0px;vertical-align:top;padding:7px 7px 7px
7px">
<div style="line-height: 1; margin-top:
0pt; margin-bottom: 0pt;">
<span style="font-size: 15px;
background-color: transparent;
vertical-align: baseline; white-space:
pre-wrap;"><font face="tahoma,
sans-serif">Keith McGuigan</font></span></div>
<div style="line-height: 1; margin-top:
0pt; margin-bottom: 0pt;">
<span style="font-size: 12px;
background-color: transparent;
vertical-align: baseline; white-space:
pre-wrap;"><font face="tahoma,
sans-serif">@kamggg</font></span></div>
<div style="line-height: 1; margin-top:
0pt; margin-bottom: 0pt;">
<a moz-do-not-send="true"
href="mailto:kmcguigan@twitter.com"
style="text-decoration:none"><span
style="font-size:12px;color:rgb(17,85,204);background-color:transparent;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"><font
face="tahoma, \
sans-serif">kmcguigan@twitter.com</font></span></a></div> </td>
</tr>
</tbody>
</table>
</div>
</span></div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic