Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of rogers.email@gmail.com
 designates 209.85.218.15 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=apABZMrNd/vHibYwdl/BDw1HbYTpnPWPWH5uxTFQytWq0pmAaUgsAhNB9VTFR7AJ/W
         HISzh7+s+k5DH8cCeQaAQdeGOqv1s/JbeB9ZkSq9zRFjVRMNOl5xR0uer4W53tHIeSeV
         5vW2qSEZ143ySxnHmHd7EjzIIQ4qKSW7t9nJo=
Message-ID: <b1e4cffb0812200711p457bcd02p98c79ae8f1edb435@mail.gmail.com>
Date: Sat, 20 Dec 2008 15:11:04 +0000
From: "Ian Rogers" <rogers.email@gmail.com>
To: dev@harmony.apache.org
Subject: Re: why do_field_sorting turned off when calculating offset for
 fields?
In-Reply-To: <255079590812190050k47c265cp360b5bca16c46984@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <255079590812182325h11fbc443gb0261910751582b3@mail.gmail.com>
	 <4bebff790812190016u3f02b53byca41cdd8f8d479e7@mail.gmail.com>
	 <e0f125db0812190026x7c053765o39b225a55886dc7b@mail.gmail.com>
	 <4bebff790812190030t746639eah9e42bfd30dc6bd9@mail.gmail.com>
	 <255079590812190050k47c265cp360b5bca16c46984@mail.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 <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.
>