<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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>
    &nbsp; <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~jiangli/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 (type&nbsp;FieldInfo)?</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. &nbsp;The number of access flags configurations is very small, much smaller than 2**16. &nbsp;(Low entropy everywhere!) &nbsp;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. &nbsp;Also, if we do field profiling we may need to add miscellaneous bits to the field metadata.</div><div><br></div><div> John</div></body></html>