<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 06/04/2013 09:00 PM, John
Cuthbertson wrote:<br>
</div>
<blockquote cite="mid:51AE3941.90609@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Everyone,<br>
<br>
Here's a new webrev for this change: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ejohnc/8015237/webrev.1">http://cr.openjdk.java.net/~johnc/8015237/webrev.1</a><br>
</blockquote>
<br>
Looks good. Thanks for doing all the cleanups.<br>
<br>
<blockquote cite="mid:51AE3941.90609@oracle.com" type="cite"> <br>
Changes from before:<br>
* Refactored the code that loops over the buckets into its own
routine.<br>
* Removed the commented out instrumentation (oops).<br>
* Changed the types to int to be consistent with the rest of
symbolTable and allow removal of the casts.<br>
* Increase the number of buckets per claim to 32 based upon a
verbal comment from John Coomes.<br>
</blockquote>
<br>
Care to describe the reasoning why 32 should be better?<br>
<br>
<blockquote cite="mid:51AE3941.90609@oracle.com" type="cite"> *
Removed the additional worker ID parameter for the sake of peace
and harmony.<br>
</blockquote>
<br>
Thanks.<br>
<br>
StefanK<br>
<br>
<blockquote cite="mid:51AE3941.90609@oracle.com" type="cite"> <br>
Testing: jprt.<br>
<br>
Thanks,<br>
<br>
JohnC<br>
<br>
<div class="moz-cite-prefix">On 5/24/2013 3:19 PM, John
Cuthbertson wrote:<br>
</div>
<blockquote cite="mid:519FE787.70408@oracle.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
Hi Everyone,<br>
<br>
Can I have a couple of reviewers look over these changes - the
webrev is: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ejohnc/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 width="485" height="104" 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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>