<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Summary:<br>
The remaining part of this bug deals with running out of address
space on 32-bit JVMs running on Win64. This fix is simply to have a
hard limit on GC threads (still larger than necessary) on 32-bit
JVMs. The new limit is 16 (2 * switch_pt).<br>
<br>
Note that this overlaps somewhat with several "# of GC thread" bugs
including:<br>
-
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<a class="issue-link" data-issue-key="JDK-8131932"
href="https://bugs.openjdk.java.net/browse/JDK-8131932"
id="key-val" rel="4836836">8131932</a>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
: Ergonomics oversize number of GC threads for small JVMs on large
systems<br>
-
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<a class="issue-link" data-issue-key="JDK-8153225"
href="https://bugs.openjdk.java.net/browse/JDK-8153225"
id="key-val" rel="4874800">8153225</a>: G1 creates too many
concurrent refinement threads by default<br>
-
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<a class="issue-link" data-issue-key="JDK-7189147"
href="https://bugs.openjdk.java.net/browse/JDK-7189147"
id="key-val" rel="4352631">7189147</a>: GC threads should be
created as needed not all at once<br>
<br>
Doing the correct thing in general will require a lot more
performance analysis. The fix here is simple, only affects 32-bit
JVMs running on >= 24 core machines, and will reduce OOM crashes
in nightly testing.<br>
<br>
BUG:
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<a class="issue-link" data-issue-key="JDK-8134889"
href="https://bugs.openjdk.java.net/browse/JDK-8134889"
id="key-val" rel="4842004">8134889</a><br>
WEBREV: <a 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>
TESTS: jprt<br>
<br>
</body>
</html>