<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Mikael,<br>
<br>
On 4/21/16 10:36 AM, Derek White wrote:<br>
</div>
<blockquote cite="mid:5718E57A.20703@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Mikael,<br>
<br>
On 4/21/16 4:02 AM, Mikael Gerdin wrote:<br>
</div>
<blockquote cite="mid:57188901.9020007@oracle.com" type="cite">Hi
Derek, <br>
<br>
On 2016-04-20 23:48, Derek White wrote: <br>
<blockquote type="cite">Still looking for reviews for a small
fix for a P2 bug... <br>
<br>
Thanks! <br>
<br>
On 4/7/16 6:07 PM, Derek White wrote: <br>
<blockquote type="cite">Summary: <br>
The remaining part of this bug deals with running out of
address space <br>
on 32-bit JVMs running on Win64. This fix is simply to have
a hard <br>
limit on GC threads (still larger than necessary) on 32-bit
JVMs. The <br>
new limit is 16 (2 * switch_pt). <br>
<br>
Note that this overlaps somewhat with several "# of GC
thread" bugs <br>
including: <br>
- 8131932 <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="https://bugs.openjdk.java.net/browse/JDK-8131932"><https://bugs.openjdk.java.net/browse/JDK-8131932></a>
: <br>
Ergonomics oversize number of GC threads for small JVMs on
large systems <br>
- 8153225 <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="https://bugs.openjdk.java.net/browse/JDK-8153225"><https://bugs.openjdk.java.net/browse/JDK-8153225></a>:
G1 <br>
creates too many concurrent refinement threads by default <br>
- 7189147 <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="https://bugs.openjdk.java.net/browse/JDK-7189147"><https://bugs.openjdk.java.net/browse/JDK-7189147></a>:
GC <br>
threads should be created as needed not all at once <br>
<br>
Doing the correct thing in general will require a lot more
performance <br>
analysis. The fix here is simple, only affects 32-bit JVMs
running on <br>
>= 24 core machines, and will reduce OOM crashes in
nightly testing. <br>
<br>
BUG: 8134889 <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="https://bugs.openjdk.java.net/browse/JDK-8134889"><https://bugs.openjdk.java.net/browse/JDK-8134889></a>
<br>
WEBREV: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edrwhite/8134889/webrev.01/">http://cr.openjdk.java.net/~drwhite/8134889/webrev.01/</a>
<br>
</blockquote>
</blockquote>
<br>
Fix looks good. <br>
I wonder about the cast to unsigned int, though. <br>
It seems weird that it's needed since all the other operands are
unsigned ints in the calculation. <br>
</blockquote>
<br>
Yes, that does look weird. I can't recall why I added it either.<br>
<blockquote><tt> unsigned int switch_pt = bar;</tt><tt><br>
</tt><tt> unsigned int threads = foo;</tt><tt><br>
</tt><tt> threads = MIN2(threads, 2*switch_pt)</tt><br>
</blockquote>
Wait a minute, according to the interweb, the type of the literal
'2' is "int" (eg. signed). I think one compiler complained on a
jprt run. Doing a jprt run without the cast...<br>
</blockquote>
So jprt is happy with or with the cast. I had the type promotion
rules wrong in my head. <br>
<tt> </tt><tt>signed * unsigned = unsigned.</tt><br>
<br>
I'll remove the cast and update the webrev.<br>
<br>
Thanks,<br>
<br>
- Derek<tt><br>
</tt>
</body>
</html>