<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi John,<br>
    <br>
    Thanks a lot for looking at the change again and the field
    compressing suggestion! I've looked into the FieldInfo array and
    optimized the memory usage for the generic signature index slot
    earlier this year. I haven't played with any compression technique.
    Thanks for the suggestion, definitely worth to look into. I have one
    question maybe you have quick answer to it. Does C1 or C2 heavily
    relying on fast accessing to the FieldInfo array?<br>
    <br>
    Thanks,<br>
    <br>
    Jiangli<br>
    <br>
    On 12/10/2012 03:10 PM, John Rose wrote:
    <blockquote
      cite="mid:0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com"
      type="cite">
      <div>
        <div>On Dec 9, 2012, at 9:53 PM, Jiangli Zhou wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <meta content="text/html; charset=windows-1252"
            http-equiv="Content-Type">
          <div text="#000000" bgcolor="#ffffff"> Hi John,<br>
            <br>
            Here is the updated webrev with Address constant change in
            where it's appropriate: <br>
            <br>
             <a moz-do-not-send="true" class="moz-txt-link-freetext"
              href="http://cr.openjdk.java.net/%7Ejiangli/8004076/webrev.01/">http://cr.openjdk.java.net/~jiangli/8004076/webrev.01/</a>.
            <br>
            <br>
            I'm also double checking with jprt and runthese tests.<br>
          </div>
        </blockquote>
      </div>
      <br>
      <div>Yes, that's much nicer; thanks.</div>
      <div><br>
      </div>
      <div>Has your group been considering compressing the field
        metadata (typeFieldInfo)?</div>
      <div><br>
      </div>
      <div>I think that, by using a variable-length byte-oriented
        format, we could easily cut the size of that data by more than
        50%.</div>
      <div><br>
      </div>
      <div>The initval field and the high part of the offset are almost
        always zero. The number of access flags configurations is very
        small, much smaller than 2**16. (Low entropy everywhere!) All
        this means they could be profitably cut out most of the time
        with profit, as long as the access method does not slow the VM
        down detectably.</div>
      <div><br>
      </div>
      <div>I'm thinking about this because of Alexey's work on
        @Contended and the upcoming work on @Stable. Also, if we do
        field profiling we may need to add miscellaneous bits to the
        field metadata.</div>
      <div><br>
      </div>
      <div> John</div>
    </blockquote>
    <br>
  </body>
</html>