<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/14/13 7:50 PM, John Cuthbertson
wrote:<br>
</div>
<blockquote cite="mid:511D31E1.1090401@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bengt, Leonid,<br>
<br>
On 2/14/2013 4:47 AM, Bengt Rutisson wrote:<br>
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><br>
Leonid,<br>
<br>
</div>
Yes, this is an interesting problem. If the buffer for the
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
OutputAnalyzer gets full before the jmap call returns we will
have a deadlock.<br>
<br>
Would you suggest that the test should spawn two processes? How
do they do the handshaking to find out when it is safe to do a
jmap call from one to the other? <br>
</blockquote>
<br>
As Mikael Gerdin has pointed out there are already a bunch of NMT
regression tests that call jcmd on themselves and I just followed
the guidelines given in Christian Tornqvist's wiki. If this is an
issue then all of these NMT tests should be removed and this
mechanism should also be removed.<br>
</blockquote>
<br>
I don't think we should remove the tests. Let's use this technique
for now. When we figure out a better way (Mikael suggested piping to
a file and reading that after the jcmd call has returned) we can go
through and fix all test that have these issues.
<blockquote cite="mid:511D31E1.1090401@oracle.com" type="cite"> <br>
Also the output of the jcmd is not that important - it's the fact
that the test didn't crash. So if there's a way avoid the
potential deadlock by disregarding the output - so be it.<br>
</blockquote>
<br>
Well, it may be ok for your test, but I'm sure there are tests that
need to verify the output.<br>
<br>
<blockquote cite="mid:511D31E1.1090401@oracle.com" type="cite">
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite"> <br>
Looking at this test again reminded me of a few more minor
things:<br>
<br>
* It would be good if the test had the "@key gc" tag that I am
just about to add. See:<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ebrutisso/8006398/webrev.01/">http://cr.openjdk.java.net/~brutisso/8006398/webrev.01/</a><br>
</blockquote>
<br>
OK. Sure.<br>
<br>
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite"> <br>
* You don't need -XX:+IgnoreUnrecognizedVMOptions in the @run
command<br>
</blockquote>
<br>
Why not? What about running on a platform where UseG1GC is not
currently supported and the flag gives an error?<br>
</blockquote>
<br>
OK. Good point. I keep forgetting that we have no control over how
and where the tests are run. This is really annoying.<br>
<br>
<blockquote cite="mid:511D31E1.1090401@oracle.com" type="cite">
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite"> <br>
* The test is in a directory called 8005875/. I again think this
is obsolete if we use the @bug tag. I would prefer to name the
folder something meaningful.<br>
</blockquote>
<br>
OK. But IMO the bug ID is meaningful. Is it any more meaningful
than TestJcmdG1AndZeroPGCT? I'm not sure. Suggest a name that you
find more meaningful.<br>
</blockquote>
<br>
My point is that if you use "@bug 8005875" then naming the directory
after the bug id does not add any information. Instead we can use
the directory name to help someone who sees a failure or who wants
to run a set of related tests. I would prefer to name the directory
something that would help group tests together.<br>
<br>
So, my suggestion would be to either place the test directly in the
gc folder or to place it in folder where we could later place
related tests. Maybe call it "g1", "parallel_threads" or "jcmd"?
Maybe none of them are perfect but at least they add new
information.<br>
<br>
Bengt<br>
<br>
<blockquote cite="mid:511D31E1.1090401@oracle.com" type="cite"> <br>
JohnC<br>
</blockquote>
<br>
</body>
</html>