<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Everyone,<br>
<br>
Can I have a couple of reviewers look over these changes - the
webrev is: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~johnc/8015237/webrev.0/">http://cr.openjdk.java.net/~johnc/8015237/webrev.0/</a><br>
<br>
Summary:<br>
On some workloads we are seeing that the scan of the intern string
table (among others) can sometimes take quite a while. This showed
up on some FMW workloads with G1 where the scan of the string table
dominated the pause time for some pauses. G1 was particularly
affected since it doesn't do class unloading (and hence pruning of
the string table) except at full GCs. The solution was to change the
string table from being considered a single root task and treat
similarly to the Java thread stacks: each GC worker claims a given
number of buckets and scans the entries in those buckets.<br>
<br>
Testing<br>
Kitchensink; jprt; GC test suite. With all collectors.<br>
<br>
Overhead:<br>
Not real performance numbers but I did some measurement of the
synchronization overhead of using 1 GC worker thread. They are
summarized here:<br>
<br>
<table height="104" width="485" border="1" cellpadding="2"
cellspacing="2">
<tbody>
<tr>
<td valign="top"><br>
</td>
<td valign="top">0-threads (ms)<br>
</td>
<td valign="top">1-thread-chunked (ms)<br>
</td>
</tr>
<tr>
<td valign="top">Min</td>
<td valign="top">0.200<br>
</td>
<td valign="top">0.300<br>
</td>
</tr>
<tr>
<td valign="top">Max</td>
<td valign="top">6.900<br>
</td>
<td valign="top">8.800<br>
</td>
</tr>
<tr>
<td valign="top">Avg</td>
<td valign="top">0.658<br>
</td>
<td valign="top">0.794<br>
</td>
</tr>
</tbody>
</table>
<br>
These were from 1 hour long runs of Kitchensink with around ~2800
GCs in each run.<br>
<br>
Thanks,<br>
<br>
JohnC<br>
</body>
</html>