<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/14/2013 04:47 PM, Bengt Rutisson
wrote:<br>
</div>
<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>
On 2/14/13 1:27 PM, Leonid Mesnik wrote:<br>
</div>
<blockquote cite="mid:511CD835.2030703@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">John<br>
<br>
This test should start failing in non-G1 baseline. Even
"IgnoreUnrecognizedVMOptions" is added I think it should fail
because of incompatible GC combinations.<br>
</div>
</blockquote>
<br>
Actually it won't fail. The test checks that the output "G1
Parallel Marking Threads" is *not* present, which it won't be for
any other collectors.<br>
<br>
It is kind of a waste to run this test for other collectors but it
won't fail. However, since the testing framework is limited and
can't handle that we need to write tests for specific GCs I think
this is how we have to write our tests.<br>
</blockquote>
Shouldn't fail here: (./share/vm/runtime/arguments.cpp)<br>
// Check consistency of GC
selection
<br>
bool Arguments::check_gc_consistency() {<br>
check_gclog_consistency();<br>
bool status = true;<br>
// Ensure that the user has not selected conflicting
sets
<br>
// of collectors. [Note: this check is merely a user
convenience;
<br>
// collectors over-ride each other so that only a
non-conflicting
<br>
// set is selected; however what the user gets is not what
they
<br>
// may have expected from the combination they asked for.
It's
<br>
// better to reduce user confusion by not allowing them
to
<br>
// select conflicting
combinations.
<br>
uint i = 0;<br>
if (UseSerialGC) i++;<br>
if (UseConcMarkSweepGC || UseParNewGC) i++;<br>
if (UseParallelGC || UseParallelOldGC) i++;<br>
if (UseG1GC) i++;<br>
if (i > 1) {<br>
jio_fprintf(defaultStream::error_stream(),<br>
"Conflicting collector combinations in option list;
"<br>
"please refer to the release notes for the
combinations "<br>
"allowed\n");<br>
status = false;<br>
}<br>
<br>
return status;<br>
}<br>
<br>
<br>
<br>
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite"> <br>
<blockquote cite="mid:511CD835.2030703@oracle.com" type="cite">
<div class="moz-cite-prefix"> Also I think that investigation
parent process from child is not safe and make analysis harder
if something going wrong. <br>
<br>
Also there was a bug 15947151 - JDK6 JMAP -HEAP LOCKS post
6u29. <br>
Here are comments from Kevin: <br>
<br>
<tt style="background-color: rgb(255, 255, 255);"><i>@ Using
Runtime.exec to launch a child process which then attaches
back to the</i> <br>
<i>@ parent to run diagnostics just sounds
risky. Diagnostics may need to suspend</i> <br>
<i>@ the parent JVM. The child needs the parent to read
buffers such that the </i><br>
<i>@ child may write. Buffering usually lets this succeed,
but there could</i> <br>
<i>@ be some risk.</i> </tt><br>
<br>
<br>
So I would prefer to avoid such schemes if we don't want to
test them. <br>
</div>
</blockquote>
<br>
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?</blockquote>
Yes<br>
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite"> 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>
We use DTonga for similar tmtools tests which includes task
synchronization. Also we have network-based sync for jdi/other
debugging tests. <br>
May be jps could be used to find process and be sure that java is
initialized or just make jmap in a loop until it returns results. <br>
<br>
Unfortunately there is no easy and generic synchronization I think.<br>
<br>
Think comments below are for John. <br>
<br>
Leonid<br>
<blockquote cite="mid:511CDCE1.6070009@oracle.com" type="cite">
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>
<br>
* You don't need -XX:+IgnoreUnrecognizedVMOptions in the @run
command<br>
<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>
<br>
Thanks,<br>
Bengt<br>
<br>
<blockquote cite="mid:511CD835.2030703@oracle.com" type="cite">
<div class="moz-cite-prefix"> <br>
Leonid<br>
<br>
On 02/14/2013 04:51 AM, John Cuthbertson wrote:<br>
</div>
<blockquote cite="mid:511C352F.5030606@oracle.com" type="cite">Hi
Everyone, <br>
<br>
Can I have a couple of volunteers review the regression test
for 8005875 - the webrev can be found at: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ejohnc/8008188/webrev.0/">http://cr.openjdk.java.net/~johnc/8008188/webrev.0/</a>
<br>
<br>
The test is very simple and issues "jcmd <pid>
Thread.print" against itself. With G1 and PGCT=0, and before
the fix for 8005875, this command crashes the VM. <br>
<br>
Testing: <br>
jdk8 build (b76) with fix for 8005875; jdk8 build (b71)
without fix for 8005875; Changed the test options to run the
test with the invalid flag -XX:+UseG2GC. <br>
<br>
Thanks, <br>
<br>
JohnC <br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Leonid Mesnik
JVM SQE</pre>
</blockquote>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Leonid Mesnik
JVM SQE</pre>
</body>
</html>