harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Rogers" <rogers.em...@gmail.com>
Subject Re: why do_field_sorting turned off when calculating offset for fields?
Date Sun, 21 Dec 2008 13:58:52 GMT
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.
>

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