<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
Hi Derek,<br>
<br>
<div class="moz-cite-prefix">On 2014-12-12 15:35, Derek White wrote:<br>
</div>
<blockquote cite="mid:548AFD2A.8060002@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">This is a request for final
re-review.<br>
<br>
Updated for comments, and added regression test for arguments.
This test is a bit overkill for this bug, but it's extensible
for other deprecated and aliased options.<br>
<br>
Re-merged with tree. <br>
<br>
Webrev: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edrwhite/8061611/webrev.01/">http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/</a><br>
</div>
</blockquote>
<br>
The code changes look good to me.<br>
<br>
A few comments about the test.<br>
<br>
I don't think it is worth testing that the removed flags produce
error messages. Starting a VM takes some time and doing it 13 times
just to check that no one by mistake added the flags back seems like
a waste of resources to me. The risk that the flags are suddenly
added back is almost zero, right?<br>
<br>
I am also not convinced that a general and extensible test is the
way to go here. I think I would prefer a more specific test for the
flags that were deprecated now. For tests I think it is more
important that the tests are easily readable and understandable than
that code duplication is avoided. Thus, I strongly prefer small but
specific tests that clearly communicates what went wrong when they
fail and are easy to understand how they failed. So, in this case
maybe we should even have two tests? TestDeprecatedMarkStackFlags
and TestDeprecatedConcGCThreadsFlags.<br>
<br>
Instead of parsing the PrintFlagsFinal output you could use
ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get
the option values and check if they are set correctly. I think that
will reduce the number of lines in the test further.<br>
<br>
Thanks,<br>
Bengt<br>
<br>
<blockquote cite="mid:548AFD2A.8060002@oracle.com" type="cite">
<div class="moz-cite-prefix"> <br>
Thanks!<br>
<br>
 - Derek<br>
<br>
On 11/18/14 11:40 AM, Derek White wrote:<br>
</div>
<blockquote cite="mid:546B7683.9000803@oracle.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Hi Team,<br>
<br>
First review request. Please let me know if I've forgotten
something or have gone completely off the rails.<br>
<br>
The main point of this bug is to remove deprecated -XX options
which are alias for other options.<br>
<br>
The only complicated part is that one case,
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<i>CMSParPromoteBlocksToClaim</i> was not a true alias for <i>OldPLABSize</i>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
but a parallel option with different defaults that were
synchronized in ergo processing. This fix removes the <i>CMSParPromoteBlocksToClaim
</i>variable but preserves using different defaults in the CMS
case.<br>
<br>
Also in this fix I added warning messages to several remaining
undocumented command line options aliases. This should ease
removal of these options in the future<br>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<pre>CMSMarkStackSize ==> MarkStackSize (MarkStackSize not documented either, but came in jdk6)
G1MarkStackSize ==> MarkStackSize
CMSMarkStackSizeMax ==> MarkStackSizeMax (MarkStackSizeMax not documented either)
ParallelMarkingThreads => ConcGCThreads (ConcGCThreads came in jdk6)
ParallelCMSThreads ==> ConcGCThread<span class="new"></span></pre>
<br>
Thanks,<br>
 - Derek<br>
<br>
<b>Webrev</b>: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edrwhite/8061611/webrev.00/">http://cr.openjdk.java.net/~drwhite/8061611/webrev.00/</a><br>
<br>
<b>Bug</b>: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8061611">https://bugs.openjdk.java.net/browse/JDK-8061611</a><br>
<br>
<b>Testing</b>:<br>
jprt:<br>
   Saw 1-2 intermittent failures that went away on retesting -
hangs and timeouts.<br>
<br>
refworkload:<br>
   no differences<br>
<br>
jtreg: Saw a few unexplained results. Not sure if typical or
not:<br>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<blockquote>
<h4>Execution failed: `main' threw exception:
java.lang.Exception: jmap -heap exited with error code: 1</h4>
<ul>
<li> <a moz-do-not-send="true"
href="http://oklahoma.us.oracle.com/net/bussund0416//export/users/drwhite/hs-gc-mine/hotspot/test/JTwork/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.jtr">gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java</a>:
Checks that jmap -heap contains the flag
CompressedClassSpaceSize </li>
</ul>
<h4>Program
`/export/users/drwhite/test-builds/j2sdk-image.11.17.2014/bin/java'
interrupted! (timed out?)</h4>
<ul>
<li> <a moz-do-not-send="true"
href="http://oklahoma.us.oracle.com/net/bussund0416//export/users/drwhite/hs-gc-mine/hotspot/test/JTwork/closed/runtime/AppCDS/SharedArchiveConsistency.jtr">closed/runtime/AppCDS/SharedArchiveConsistency.java</a>:
SharedArchiveConsistency </li>
</ul>
Plus a bunch of tests that are labelled "ignored".<br>
</blockquote>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<p><br>
</p>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>