You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by xiaoming gu <xi...@gmail.com> on 2008/12/19 08:25:10 UTC
why do_field_sorting turned off when calculating offset for fields?
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.
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by xiaoming gu <xi...@gmail.com>.
Got it. Thanks. -Xiaoming
On Sun, Dec 21, 2008 at 9:58 PM, Ian Rogers <ro...@gmail.com> wrote:
> 2008/12/21 xiaoming gu <xi...@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 <ro...@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 <xi...@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 <pm...@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
> >> >> > <al...@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.
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by Ian Rogers <ro...@gmail.com>.
2008/12/21 xiaoming gu <xi...@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 <ro...@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 <xi...@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 <pm...@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
>> >> > <al...@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.
>
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by xiaoming gu <xi...@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
On Sat, Dec 20, 2008 at 11:11 PM, Ian Rogers <ro...@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 <xi...@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 <pm...@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
> >> > <al...@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.
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by Ian Rogers <ro...@gmail.com>.
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 <xi...@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 <pm...@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
>> > <al...@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 <xi...@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.
>
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by xiaoming gu <xi...@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 <pm...@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
> > <al...@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 <xi...@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.
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by Aleksey Shipilev <al...@gmail.com>.
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 <pm...@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
> <al...@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 <xi...@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.
>>>
>>
>
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by Pavel Pervov <pm...@gmail.com>.
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
<al...@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 <xi...@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.
>>
>
Re: why do_field_sorting turned off when calculating offset for fields?
Posted by Aleksey Shipilev <al...@gmail.com>.
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 <xi...@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.
>