<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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. &nbsp;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. &nbsp;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. &nbsp;The FieldStream would unpack each successive field descriptor into the FieldInfo structure. &nbsp;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-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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. &nbsp;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. &nbsp;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. &nbsp;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></body></html>