<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>
<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 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. 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></body></html>