<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi John,<br>
    <br>
    Thanks! Following are some more questions.<br>
    <br>
    I see CompressedStream uses UNSIGNED5 coding of Pack200. I tried to
    google around for the UNSIGNED5 coding compression rate, but without
    much luck. If you have any info on that, please share. I was trying
    to find some usage examples in the VM code, but there seems no usage
    of CompressedStream (except the sa agent java code). Do you have any
    pointer?<br>
    <br>
    Thanks,<br>
    Jiangli<br>
    <br>
    On 12/11/2012 05:02 PM, John Rose wrote:
    <blockquote
      cite="mid:7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com"
      type="cite">
      <div>
        <div>On Dec 10, 2012, at 3:30 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>
            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>
          </div>
        </blockquote>
      </div>
      <br>
      <div>A couple of other bits...</div>
      <div><br>
      </div>
      <div>I sketched more of a compact design during Alexsey's review:</div>
      <div><br>
      </div>
      <div>On Dec 11, 2012, at 3:21 PM, John Rose wrote:</div>
      <div><br class="Apple-interchange-newline">
        <blockquote type="cite"><span class="Apple-style-span"
            style="border-collapse: separate; font-family: Helvetica;
            font-style: normal; font-variant: normal; font-weight:
            normal; letter-spacing: normal; line-height: normal;
            orphans: 2; text-indent: 0px; text-transform: none;
            white-space: normal; widows: 2; word-spacing: 0px;
            font-size: medium;">On Dec 11, 2012, at 5:06 AM, Aleksey
            Shipilev wrote:<br>
            <br>
            <blockquote type="cite">
              <blockquote type="cite">...The rework could use something
                like your tagging<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">scheme (which is clever) but have
                the exceptional tag value mean "I<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">have extended attributes specified
                in N additional words of data".<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite"><br>
            </blockquote>
            <blockquote type="cite">I think we have a little bit of
              mis-design about FieldInfo here. What<br>
            </blockquote>
            <blockquote type="cite">allows me to piggyback on FieldInfo
              is that we clearly have the<br>
            </blockquote>
            <blockquote type="cite">classload-scope (CS) metadata info
              for fields, and runtime-scope (RS)<br>
            </blockquote>
            <blockquote type="cite">metadata info. That allows us to
              mangle CS data during the classload,<br>
            </blockquote>
            <blockquote type="cite">knowing for sure we substitute that
              with RS after classload finishes.<br>
            </blockquote>
            <blockquote type="cite"><br>
            </blockquote>
            <blockquote type="cite">This is probably a little dodgy when
              compared against sparse<br>
            </blockquote>
            <blockquote type="cite">representation, but I feel
              uncomfortable rebuilding entire field<br>
            </blockquote>
            <blockquote type="cite">attribute mechanics in the course of
              @Contended work.<br>
            </blockquote>
            <br>
            It's totally dodgy. It makes some sense if you are aiming
            at an in-memory copy of the classfile AST, but is not
            friendly to the JVM which is actually using the data. If I
            were rewriting it, I would try to use a temporary FieldInfo
            structure with a simple but non-dense layout, and a packing
            phase which would put the necessary field metadata into a
            dense streamable form, in an array&lt;u1&gt;, using
            CompressedStream. The FieldStream would unpack each
            successive field descriptor into the FieldInfo structure.
            By using CompressedStream, the data structure would be
            32-bit clean, leading to various other advantages.<br>
          </span></blockquote>
      </div>
      <div><span class="Apple-style-span" style="border-collapse:
          separate; font-family: Helvetica; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: normal; orphans: 2; text-indent: 0px;
          text-transform: none; white-space: normal; widows: 2;
          word-spacing: 0px; font-size: medium;"><br>
        </span></div>
      <div><span class="Apple-style-span" style="border-collapse:
          separate; font-family: Helvetica; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: normal; orphans: 2; text-indent: 0px;
          text-transform: none; white-space: normal; widows: 2;
          word-spacing: 0px; font-size: medium;">In general, I think we
          should make more systematic use of CompressedStream for
          storing metadata that is not directly accessed by the
          interpreter or compiled code.</span></div>
      <div><br>
      </div>
      <div>Also, I did a quick and dirty "printf" based test for average
        field-info array size. It suggests that about 30% of the
        classes have one or more fields, and that of those classes, the
        average array length is 36 (u2) elements. This is pretty small
        potatoes, but it's of similar magnitude to the other bit-packing
        changes to InstanceKlass, so maybe it's worth while. I
        definitely think using CompressedStream in more places is
        worthwhile, if we want to pack our metadata down tighter, and at
        the same time move toward 32-bit clean representations.</div>
      <div><br>
      </div>
      <div>Thanks,</div>
      <div> John</div>
    </blockquote>
    <br>
  </body>
</html>