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 13:09:03 GMT
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

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