<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 4/21/2015 1:56 PM, Derek White
wrote:<br>
</div>
<blockquote cite="mid:5536B981.80307@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">Thanks Jon!<br>
<br>
On 4/21/15 1:23 PM, Jon Masamitsu wrote:<br>
</div>
<blockquote cite="mid:553687A0.8090802@oracle.com" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
Derek,<br>
<br>
Thanks for fixing this.<br>
<br>
Fix looks good.<br>
<br>
What do you think about always making
testDynamicNumberOfGCThread()<br>
check for the uniprocessor case (as opposed to passing in a flag
to explicitly<br>
check it)? <br>
</blockquote>
This may not catch all of the failures. What I couldn't pin down
was why some 2, 3(!), or 4 core ARM machines would result in
defaulting ParallelGCThreads=1. Now these were embedded machines,
with potentially "odd" versions of linux, possibly with "odd"
errata. Or perhaps there was some dynamic differences between
"installed" and "on-line" cores.<br>
<br>
In any case the safest test seemed to be to force
ParallelGCThreads=1 and see if it works.<br>
</blockquote>
<br>
I don't think I said it right. What I meant was that
testDynamicNumberOfGCThread()<br>
should always test both cases (emulate_uniprocessor true and false)
instead of calling<br>
testDynamicNumberOfGCThread() twice, once with emulate_uniprocessor
true and once<br>
with emulate_uniprocessor false. Was that what you responded to?<br>
<br>
Jon<br>
<br>
<br>
<blockquote cite="mid:5536B981.80307@oracle.com" type="cite">
<blockquote cite="mid:553687A0.8090802@oracle.com" type="cite">
ForceDynamicNumberOfGCThreads is a diagnostic flag<br>
<br>
diagnostic(bool, ForceDynamicNumberOfGCThreads,
false, \<br>
"Force dynamic selection of the number of
" \<br>
"parallel threads parallel gc will use to aid
debugging") \<br>
<br>
so I think you need +UnlockDiagnosticVMOptions.<br>
</blockquote>
OK. <br>
<blockquote cite="mid:553687A0.8090802@oracle.com" type="cite">
<div class="moz-cite-prefix">On 04/21/2015 06:53 AM, Derek White
wrote:<br>
</div>
<blockquote cite="mid:5536563F.4020806@oracle.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<tt>Hi All,</tt><tt><br>
</tt><tt><br>
</tt><tt>Please review this fix for: <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8076995">https://bugs.openjdk.java.net/browse/JDK-8076995</a></tt><br>
<pre wrap="">Webrev:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/%7Edrwhite/8076995/webrev.00/">http://cr.openjdk.java.net/~drwhite/8076995/webrev.00/</a>
Summary:
Part 1 is a test bug that tries to run G1 on embedded SE builds. Not changed by this webrev.</pre>
</blockquote>
</blockquote>
<br>
Looking into changing TEST.group...<br>
<br>
BTW, I tested with jprt earlier, but I'll try to get an Aurora run
in.<br>
<br>
<br>
- Derek<br>
<blockquote cite="mid:553687A0.8090802@oracle.com" type="cite">
<blockquote cite="mid:5536563F.4020806@oracle.com" type="cite">
<pre wrap="">
Part two is assertion failure that is being fixed by this webrev.
This is a fix for bug that triggered an assert when running CMS on very
small machines - 1 core x86, or 1-4 core ARM. This may seem unlikely but
can easily happen when running virtual instances.
Failure stack traces also show bug crashing printing a stack trace, but this is being tracked in another bug.
Thanks,
- Derek
</pre>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>