Hi David,<div><br></div><div>I&#39;ll let Vladimir, the original author, give the definitive answer. :-)</div><div><br></div><div>Anyway, here&#39;s my guess:</div><div>Packing oop fields together makes iterating oops in an object faster. For example, the marking phase of GC would benefit from this.</div>

<div><br></div><div>Supposed we had a few classes as follows:</div><div><br></div><div>class Base {</div><div>  Object o1;</div><div>  int i;</div><div>}</div><div><br></div><div>class Derived extends Base {</div><div>  Object o2;</div>

<div>  float f;</div><div>}</div><div><br></div><div>An instance of Derived would contain a Base subobject within itself.</div><div>It&#39;s straightforward to keep the Base&#39;s field layout in the subobject in an Derived instance; in other words, Base::o1 and Base::i would be at the same offset in a Base instance and in a Derived instance.</div>

<div><br></div><div>So, to pack oops in Base and Derived together while keeping Base&#39;s layout intact in Derived, a reasonable solution is to alternate between FieldsAllocationStyle=1 and FieldsAllocationStyle=0 in an inheritance chain. That&#39;s exactly what FieldsAllocationStyle is doing.</div>

<div><br></div><div>But if we push hard to pack all oop fields in an object together, we&#39;d probably end up using a bidirectional object layout, like the one used in SableVM (<a href="http://www.sablevm.org/features.html" target="_blank">http://www.sablevm.org/features.html</a>). It&#39;d be really fun to see this implemented in HotSpot VM sometime in the future.</div>
<div><br></div><div>This paper is worth reading if you&#39;re interested in object layouts:</div><div>A Comprehensive Evaluation of Object Scanning Techniques, <a href="http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan-ismm-2011.pdf">http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan-ismm-2011.pdf</a></div>

<div><br></div><div>Regards,</div><div>Kris Mok</div><div><br><div class="gmail_quote">On Thu, Jun 23, 2011 at 2:29 AM, David Dabbs <span dir="ltr">&lt;<a href="mailto:dmdabbs@gmail.com" target="_blank">dmdabbs@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:hotspot-dev-bounces@openjdk.java.net" target="_blank">hotspot-dev-bounces@openjdk.java.net</a> [mailto:<a href="mailto:hotspot-dev-" target="_blank">hotspot-dev-</a><br>
&gt; <a href="mailto:bounces@openjdk.java.net" target="_blank">bounces@openjdk.java.net</a>] On Behalf Of Vladimir Kozlov<br>
&gt; Sent: Wednesday, June 22, 2011 12:39 PM<br>
&gt; To: Krystal Mok<br>
&gt; Cc: hotspot-dev<br>
&gt; Subject: Re: Bug in FieldsAllocationStyle=2 logic<br>
<div><div></div><div>&gt;<br>
&gt; Thank you for such detail analysis and suggested fix.<br>
&gt; I filed bug and I will fix it in 7u2.<br>
&gt;<br>
&gt; 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Vladimir<br>
&gt;<br>
&gt; PS: if possible, please, report problems to hotspot-<br>
&gt; <a href="mailto:dev@openjdk.java.net" target="_blank">dev@openjdk.java.net</a> alias<br>
&gt; so all Hotspot developers can see it. I did original changes but I am<br>
&gt; in<br>
&gt; Compiler (JIT) group.<br>
&gt;<br>
&gt; Krystal Mok wrote:<br>
&gt; &gt; Hi all,<br>
&gt; &gt;<br>
&gt; &gt; I think I&#39;ve found a bug in ClassFileParser::parseClassFile() that<br>
&gt; deals<br>
&gt; &gt; with FieldsAllocationStyle=2, which was introduced about a year<br>
&gt; &gt; ago: <a href="http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743" target="_blank">http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743</a><br>
&gt; &gt;<br>
&gt; &gt; int map_size = super_klass-&gt;nonstatic_oop_map_size();<br>
&gt; &gt; OopMapBlock* first_map = super_klass-&gt;start_of_nonstatic_oop_maps();<br>
&gt; &gt; OopMapBlock* last_map = first_map + map_size - 1;<br>
&gt; &gt;<br>
&gt; &gt; This code accidentally works on LP64 systems because it takes 1 word<br>
&gt; per<br>
&gt; &gt; OopMapBlock, so nonstatic_oop_map_size() and<br>
&gt; nonstatic_oop_map_count()<br>
&gt; &gt; would actually return the same value.<br>
&gt; &gt;<br>
&gt; &gt; But on 32-bit systems, an OopMapBlock takes 2 words, which<br>
&gt; &gt; makes nonstatic_oop_map_size() == nonstatic_oop_map_count() * 2, and<br>
&gt; &gt; breaks the code above.<br>
&gt; &gt;<br>
&gt; &gt; The code should really be:<br>
&gt; &gt;<br>
&gt; &gt; int map_count = super_klass-&gt;nonstatic_oop_map_count();<br>
&gt; &gt; OopMapBlock* first_map = super_klass-&gt;start_of_nonstatic_oop_maps();<br>
&gt; &gt; OopMapBlock* last_map = first_map + map_count - 1;<br>
&gt; &gt;<br>
&gt; &gt; I found this because FieldsAllocationStyle=2 doesn&#39;t work for me on<br>
&gt; &gt; 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu<br>
&gt; JDK6u25.<br>
&gt; &gt; Here&#39;s a min repro of my test: <a href="https://gist.github.com/1037866" target="_blank">https://gist.github.com/1037866</a><br>
&gt; &gt;<br>
&gt; &gt; Could anybody please verify this?<br>
&gt; &gt; Just checked the current tip of hsx/hotspot-rt, and it still has this<br>
&gt; &gt; behavior:<br>
&gt; &gt; <a href="http://hg.openjdk.java.net/hsx/hotspot-" target="_blank">http://hg.openjdk.java.net/hsx/hotspot-</a><br>
&gt; rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp<br>
&gt; &gt; line 3290<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; Kris Mok<br>
<br>
<br>
</div></div>What would be the use case/work load for choosing this option?<br>
<br>
<br>
Thanks,<br>
<font color="#888888"><br>
David<br>
<br>
<br>
</font></blockquote></div><br></div>