<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 2:57 PM, bill pittore
wrote:<br>
</div>
<blockquote cite="mid:5536C7BE.4000405@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 4/21/2015 4: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>
</blockquote>
There is definitely a difference between the processor count and
the online processor count. It seems that the calculation of
ParallelGCThreads uses the online count which could easily be 1 on
some embedded platform since the kernel does do active power
management by shutting off cores. The comment in os.hpp for
active_processor_count() says "Returns the number of CPUs this
process is currently allowed to run on". On linux at least I
don't think that's correct. Cores could be powered down just
because the kernel is in some low power state and not because of
some affinity property for this particular Java process. I'd
change the calculation to call processor_count() instead of
active_processor_count().<br>
</blockquote>
<br>
An early implementation used processor_count() and there was some
issue with virtualization.<br>
I forget what the virtualization was but it was something like
Solaris containers or zones. Let me<br>
call them containers. A container on an 8 processor machine might
only get 1 processor but<br>
processor_count() would return 8. It may also have been on a
system where there were 8<br>
processors but 7 were disabled. Only 1 processor was available to
execute the JVM but<br>
processor_count() returned 8. Anyway, if anyone thinks it should be
processor_count()<br>
instead of active_processor_count(), check those types of
situations.<br>
<br>
Jon<br>
<br>
<blockquote cite="mid:5536C7BE.4000405@oracle.com" type="cite"> <br>
bill<br>
<br>
<blockquote cite="mid:5536B981.80307@oracle.com" type="cite"> <br>
In any case the safest test seemed to be to force
ParallelGCThreads=1 and see if it works.<br>
<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>
</blockquote>
<br>
</body>
</html>