<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Stefan,<br>
<br>
I think it was for aesthetics. 20 looked odd (even though it's even)
:)<br>
<br>
I went with 32 because a lower number would increase the number of
atomic operations. 128 seemed too high for the old default table
size on the haswell system I was testing on. So 32 and 64 seemed to
be the Goldilocks values. I chose 32.<br>
<br>
JohnC<br>
<br>
<div class="moz-cite-prefix">On 6/5/2013 11:03 AM, Stefan Karlsson
wrote:<br>
</div>
<blockquote cite="mid:51AF7D6C.7010808@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 6/5/13 7:05 PM, John Cuthbertson
wrote:<br>
</div>
<blockquote cite="mid:51AF6FC8.5070501@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Hi Stefan,<br>
<br>
He wanted a power of two. <br>
</blockquote>
<br>
And the reason being?<br>
<br>
It won't help the cache alignment "issues" that Per talked about
earlier, if that's the reason. The array will still not be aligned
against a cache line size.<br>
<br>
Anyways, I'm happy with the change.<br>
<br>
StefanK<br>
<blockquote cite="mid:51AF6FC8.5070501@oracle.com" type="cite"> <br>
JohnC<br>
<br>
<div class="moz-cite-prefix">On 6/5/2013 4:10 AM, Stefan
Karlsson wrote:<br>
</div>
<blockquote cite="mid:51AF1C96.4070404@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<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 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>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>