harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "xiaoming gu" <xiaoming...@gmail.com>
Subject Re: why do_field_sorting turned off when calculating offset for fields?
Date Sun, 21 Dec 2008 14:39:12 GMT
Got it. Thanks. -Xiaoming

On Sun, Dec 21, 2008 at 9:58 PM, Ian Rogers <rogers.email@gmail.com> wrote:

> 2008/12/21 xiaoming gu <xiaoming.gu@gmail.com>:
> > 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 <rogers.email@gmail.com>
> 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 <xiaoming.gu@gmail.com>:
> >> > It's worth trying. Thanks. -Xiaoming
> >> >
> >> > On Fri, Dec 19, 2008 at 4:30 PM, Aleksey Shipilev <
> >> > aleksey.shipilev@gmail.com> 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 <pmcfirst@gmail.com>
> >> 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
> >> >> > <aleksey.shipilev@gmail.com> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message