<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Leonid,<br>
<br>
On 2/14/13 2:15 PM, Leonid Mesnik wrote:<br>
</div>
<blockquote cite="mid:511CE375.1080008@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<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>
</blockquote>
<br>
Yes, you are probably correct. This is why we need this bug fixe as
soon as possible:<br>
<br>
INTJDK-7185557: Tests written for specific collector need to ignore
global settings <br>
<a class="moz-txt-link-freetext" href="https://jbs.oracle.com/bugs/browse/INTJDK-7185557">https://jbs.oracle.com/bugs/browse/INTJDK-7185557</a><br>
<br>
It is a P2 that has not been touched for half a year.<br>
<br>
Bengt<br>
<br>
<blockquote cite="mid:511CE375.1080008@oracle.com" type="cite"> <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>
</blockquote>
<br>
</body>
</html>