Got it. Thanks. -Xiaoming On Sun, Dec 21, 2008 at 9:58 PM, Ian Rogers <[email protected]> wrote:
> 2008/12/21 xiaoming gu <[email protected]>: > > Quite useful information. I'm a little bit confused about "In GCJ fields > are > > laid out largest to smallest and then for a sub-class from smallest to > > largest." Why the first part is from largest to smallest but the second > part > > is from smallest to largest? Would you explain more clearly, Ian? Thanks. > > > > Xiaoming > > Hi Xiaoming, > > here's an example: > > class foo { > int x; > boolean a; > } > class boo extends foo { > int y; > boolean b; > } > class bar extends boo { > int z; > boolean c; > } > > In GCJ the layout of foo will be: > > 01234567 (byte offset) > xxxxa... (. = unused) > > the layout of boo will be: > > 0123456789ab (byte offset) > xxxxab..yyyy (. = unused) > > and the layout of bar will be: > > 0123456789abcdef0123 (byte offset) > xxxxab..yyyyzzzzc... (. = unused) > > By laying the fields of the sub-class out in the reverse order, gaps at the > end of the parent class can be used by the sub-class. However, gaps cannot > be used by a sub-subclass so space could be wasted (5 bytes if objects are > multiples of 4 bytes in size, often this figure is 16 bytes so much more > space is wasted). > > In Jikes RVM the layout of foo and boo are the same, the layout of bar will > be: > > 0123456789abcdef (byte offset) > xxxxabc.yyyyzzzz (. = unused) > > Jikes RVM tracks the 1, 2 or 4 byte holes that exist in classes. As we pack > this information we can't handle tracking holes if they are at spaces > greater than a few kilobytes (but such objects are very rare). This means > tracking holes doesn't really cost us any more in space than tracking the > true size of the object (as GCJ has to). > > Regards, > Ian > > > On Sat, Dec 20, 2008 at 11:11 PM, Ian Rogers <[email protected]> > wrote: > > > >> Hi, > >> > >> sorry to be slightly off-topic but I thought I'd describe how we do > >> the field layout in Jikes RVM and how the field lay out is done in GCJ > >> as it seems to be relevant here. In GCJ fields are laid out largest to > >> smallest and then for a sub-class from smallest to largest. This > >> allows an object with say an int and a boolean with a subclass with an > >> int and a boolean to occupy the space of 3 ints (the 2 booleans appear > >> in the middle int). In Jikes RVM we lay fields out from largest to > >> smallest and track holes. Holes are created by alignment. When a hole > >> can be consumed it is, rather than adding to the size of the object. > >> This means that sub-class fields can be laid out inside the super > >> class if the super class contains holes [1]. When this work was > >> originally done it was a big win for Jikes RVM as GCs were less > >> frequent. The effect on locality could do with better investigation. > >> > >> Regards, > >> Ian > >> > >> [1] > >> > > http://jikesrvm.svn.sf.net/viewvc/jikesrvm/rvmroot/trunk/rvm/src/org/jikesrvm/objectmodel/FieldLayoutPacked.java?revision=14507&view=markup > >> > >> 2008/12/19 xiaoming gu <[email protected]>: > >> > It's worth trying. Thanks. -Xiaoming > >> > > >> > On Fri, Dec 19, 2008 at 4:30 PM, Aleksey Shipilev < > >> > [email protected]> wrote: > >> > > >> >> Yeah, Pavel is more correct. That functionality was from very > >> >> beginning and [1] just exposed the options to the public :) Xiaoming, > >> >> you may try to run SPECjvm2008/DaCapo with this option turned on/off > >> >> to measure performance impact. > >> >> > >> >> Thanks, > >> >> Aleksey. > >> >> > >> >> On Fri, Dec 19, 2008 at 11:26 AM, Pavel Pervov <[email protected]> > >> wrote: > >> >> > These options were always available in DRLVM, and [1] only made > them > >> >> > available for configuration from command line. > >> >> > > >> >> > Pavel. > >> >> > > >> >> > P.S. I can also recall some issues related to changing order of > fields > >> >> > which were introducing measurable preformance loss on various > >> >> > benchmarks. > >> >> > > >> >> > On Fri, Dec 19, 2008 at 11:16 AM, Aleksey Shipilev > >> >> > <[email protected]> wrote: > >> >> >> Hi, Xiaoming! > >> >> >> > >> >> >> If I recall correctly, field sorting incurs some performance > >> >> >> degradations on some of SPECjvm2008 benchmarks. But it helps > >> >> >> SPECjbb2005 a lot, say +1-2%. Here's the issue [1], where these > >> >> >> options were introduced. > >> >> >> > >> >> >> Thanks, > >> >> >> Aleksey. > >> >> >> > >> >> >> [1] https://issues.apache.org/jira/browse/HARMONY-5040 > >> >> >> > >> >> >> On Fri, Dec 19, 2008 at 10:25 AM, xiaoming gu <xiaoming.gu@ > gmail.com > >> > > >> >> wrote: > >> >> >>> Hi, all. I'm studying fields' offsets these days. I find there > are > >> some > >> >> >>> ordering operations for instance fields and static fields > seperately > >> in > >> >> >>> assign_offsets_to_fields() in Prepare.cpp. These orderings are > >> >> according to > >> >> >>> field size to reduce internal fragmentation. I don't know why > such > >> >> >>> operations are turned off by default. Is there any concern I > missed? > >> >> Thanks. > >> >> >>> > >> >> >>> Xiaoming > >> >> >>> > >> >> >>> -- > >> >> >>> I believe that unarmed truth and unconditional love will have the > >> final > >> >> word > >> >> >>> in reality. --Martin Luther King Jr. > >> >> >>> > >> >> >> > >> >> > > >> >> > >> > > >> > > >> > > >> > -- > >> > I believe that unarmed truth and unconditional love will have the > final > >> word > >> > in reality. --Martin Luther King Jr. > >> > > >> > > > > > > > > -- > > I believe that unarmed truth and unconditional love will have the final > word > > in reality. --Martin Luther King Jr. > > > -- I believe that unarmed truth and unconditional love will have the final word in reality. --Martin Luther King Jr.
