<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 05/27/2013 09:16 PM, Stefan Karlsson
      wrote:<br>
    </div>
    <blockquote cite="mid:51A3B110.6050502@oracle.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 2013-05-25 00:19, 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>
      </blockquote>
      <br>
      Not a complete review, yet. But I have a couple of comments from
      browsing through the patch.<br>
      <br>
      There's a lot of places where you have add an extra worker_id
      parameter. It's only used for one out-commented print statement
      and a very toothless assert. If you remove that, the patch will
      shrink from ten files changed to three files changed and we'll
      keep the process_strong_roots functions from getting more
      parameters.<br>
      <br>
      Have you also consider to parallelize the StringTable::unlink
      function? <br>
    </blockquote>
    <br>
    I've looked through the patch and I think it looks good.<br>
    <br>
    However, I think that you should remove the added worker_id
    parameters and I sympathize with Thomas' concern about the code
    duplication.<br>
    <br>
    thanks,<br>
    StefanK<br>
    <blockquote cite="mid:51A3B110.6050502@oracle.com" type="cite"> <br>
      thanks,<br>
      StefanK<br>
      <br>
      <blockquote cite="mid:519FE787.70408@oracle.com" type="cite">
        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>