Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of wuyuehao@gmail.com designates
 209.85.142.190 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=PTsB0SBCzmoJmPO1rPxUgfAqhDbmtIv3AEG+3t8AIRGrkpf5gcSP+U+1E9v8FcVO12QBlhyZQ0KMeEZVYzRJQoGmRgHh4uKHTokGlogWV8Ma86fXsGjf4Y6nu7+HOcyFe+2N1YvXRyH3g6dET6JmaC5Ln7VyxgAsLkaurk5UGE0=
Message-ID: <211709bc0802090725j48e6060er120924b124e5dca5@mail.gmail.com>
Date: Sat, 9 Feb 2008 23:25:54 +0800
From: "Tony Wu" <wuyuehao@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib]remove the duplicate locale data
In-Reply-To: <e0f125db0802060820q19eec9eg941e7c42516359ab@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <211709bc0711050033o55158d22mad9dce73f8ad4490@mail.gmail.com>
	 <4bebff790801140808j4ca10824mc9e3733032a0ca9a@mail.gmail.com>
	 <478B8C0A.8070307@gmail.com>
	 <20080114173811.7D7AB4DA0B8@nike.apache.org>
	 <211709bc0801150252x1b902c05r678eb14be29c8718@mail.gmail.com>
	 <4bebff790801160829t140aaa4fh8860a3a694e9263b@mail.gmail.com>
	 <211709bc0801202317t460cb1ebg7f2830fba9145e5@mail.gmail.com>
	 <4bebff790801220949j2a56d590nf00e5534cf7723c0@mail.gmail.com>
	 <211709bc0801222341v43cf8f78y4af209410f674928@mail.gmail.com>
	 <e0f125db0802060820q19eec9eg941e7c42516359ab@mail.gmail.com>

On 2/7/08, Pavel Pervov <pmcfirst@gmail.com> wrote:
> Tony,
>
> Unfortunately, I have a number of JIRAs for you. They all are
> regressions after removing duplicate locale data.
>
> Here they go:
>
Hi, Pavel and all
my solution below

> https://issues.apache.org/jira/browse/HARMONY-5459
Fixed, thanks for your patch.
> https://issues.apache.org/jira/browse/HARMONY-5461
Can not reproduce
> https://issues.apache.org/jira/browse/HARMONY-5465
Reported to ICU before. ICU refused to fix but we can work around it
if necessary. Need your suggestion.
> https://issues.apache.org/jira/browse/HARMONY-5466
non-bug difference, due to CLDR data.
> https://issues.apache.org/jira/browse/HARMONY-5467
non-bug difference, due to CLDR data.
> https://issues.apache.org/jira/browse/HARMONY-5468
report to http://bugs.icu-project.org/trac/ticket/6174
> https://issues.apache.org/jira/browse/HARMONY-5469
I suppose it is another CLDR data difference, need your commets.


>
> I would like to know your opinion on whether they should be fixed of
> resolved some other way.
>
> Thanks,
>    Pavel.
>
> P.S. There is also HARMONY-5013 which was introduced with moving to
> ICU4J 3.8. Could you, please, look at that issue too?
>
> On 1/23/08, Tony Wu <wuyuehao@gmail.com> wrote:
> > Thanks very much, so we got 4MB src code cutted w/o pay. Cheer!
> >
> > On 1/23/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> > > Hi Tony,
> > >
> > > The good thing is, after the commit I have compared revisions 610727
> > > (before your commit) and 612866 (after your commit) and haven't
> > > noticed degradation while running SPECjbb2005 in 2-VM configuration.
> > > That's definitely good news :)
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > On Jan 21, 2008 10:17 AM, Tony Wu <wuyuehao@gmail.com> wrote:
> > > > Thanks, Aleksey and all
> > > >
> > > > patch committed at r612718. Then I'm going to deal with the non-bug
> > > > difference. Hopefully many legcy bugs/differences can be fixed this
> > > > time.
> > > >
> > > >
> > > > On 1/17/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> > > > > Hi, guys!
> > > > >
> > > > > Sure, correctness is important, but performance is important too. I
> > > > > had profiled both versions (clean and patched) and see no significant
> > > > > difference there: there are more GC happens what I believe connected
> > > > > to internal ICU object creation and such. So, there are no obvious way
> > > > > to maintain the same performance level, and may be we will try again
> > > > > to eliminate ICU usage from the hotpath of frequently used workloads -
> > > > > but previous investigation shows it's not that simple.
> > > > >
> > > > > Tony, please go ahead with committing this patch, we will deal with
> > > > > ICU performance issues a little later.
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > On Jan 15, 2008 1:52 PM, Tony Wu <wuyuehao@gmail.com> wrote:
> > > > > > Hi Aleksey,
> > > > > >
> > > > > > Thanks for you help.
> > > > > >
> > > > > > I've proved there is no performance degradation on my machine
> > > > > > mentioned in my previous mail. I suppose the different result on your
> > > > > > machine is caused by different options to SpecJBB. Anyway, my POV is
> > > > > > that we should be willing to pay for the adoption of ICU if we have
> > > > > > to. All of us should be positive on this point. I'd like to clarify
> > > > > > the factors I'm facing below.
> > > > > >
> > > > > > Firstly, the original implementation of harmony is faster but
> > > > > > incorrect. It is not reasonable to keep the code as is and refuse to
> > > > > > correct it just because the bad version has better performance. IMHO
> > > > > > performance is nothing if there is no correctness.
> > > > > >
> > > > > > Secondly, we adopt ICU through delegation which involves extra method
> > > > > > calls than we implement it by ourselves, it does harm to performance
> > > > > > and can not be worked around. But please do not forget we benefit from
> > > > > > ICU in bug fixing, maintenance, smaller code size and so on.
> > > > > >
> > > > > > Lastly, branching does not make sense to me. My fix is very separate
> > > > > > in luni and text, I can not guarantee that there is no modification
> > > > > > during my work, so the synchronization between HEAD and my branch is
> > > > > > required. Actually only I myself am working on the development work
> > > > > > (Surely, Aleksey is very helpful on testing), this synchronization
> > > > > > might be a nightmare to me. Furthermore, the code on branch will not
> > > > > > be automatically tested by continuous integration system and BTI, I do
> > > > > > not want to work without collaboration, that's not an open source
> > > > > > style, right? Will you ask a contributor to create a branch and play
> > > > > > with himself whenever he wants to contribute?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 1/15/08, Mark Hindess <mark.hindess@googlemail.com> wrote:
> > > > > > >
> > > > > > > On 14 January 2008 at 16:21, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > > > > > > > Aleksey Shipilev wrote:
> > > > > > > > > Yep, Tim, you're right. I believe that new implementation fixes a
> > > > > > > > > number of bugs and will try to get it not degrading. I just want to
> > > > > > > > > maintain the performance level of current trunk on the same level,
> > > > > > > > > gradually fixing functional bugs. I don't like to sacrifice
> > > > > > > > > performance of HEAD revision for non-critical bugfix. That is, I want
> > > > > > > > > to see HEAD changes like this:
> > > > > > > > >
> > > > > > > > > "high performance, minor bug -> high performance, no bugs"
> > > > > > > > >
> > > > > > > > > rather than
> > > > > > > > >
> > > > > > > > > "high performance, minor bug -> low performance, no bugs -> high
> > > > > > > > > performance, no bugs"
> > > > > > > > >
> > > > > > > > > ...because anyone could get the HEAD Harmony revision for
> > > > > > > > > performance measurements at any time.
> > > > > > >
> > > > > > > Couldn't someone also get the HEAD Harmony revision and suffer from the
> > > > > > > known/fixable-with-Tony's-patch bugs at any time?
> > > > > > >
> > > > > > > > > What do you think?
> > > > > > >
> > > > > > > > For sure, improving performance and fixing the bugs is the most
> > > > > > > > desirable state.  I actually don't mind some minor performance
> > > > > > > > regression on HEAD between releases provided it is an area being
> > > > > > > > actively worked upon.
> > > > > > >
> > > > > > > +1 especially if it fixes bugs
> > > > > > >
> > > > > > > > I'd also like to get to 4.2Mb source code reduction too ;-)
> > > > > > >
> > > > > > > Me too.
> > > > > > >
> > > > > > > > If you and Tony are happy to work on the patch to get it perfect then
> > > > > > > > go ahead.  I hope it is not too troublesome to keep it in synch.  You
> > > > > > > > could also consider a branch in SVN.
> > > > > > >
> > > > > > > This bothers me too.  Firstly, while it is being developed in patch
> > > > > > > on JIRA, it is likely only Tony and Aleksey will really look at it.
> > > > > > > Secondly, that progress will be slow because of the cost of keeping in
> > > > > > > sync - this applies to an SVN branch too.
> > > > > > >
> > > > > > > I can't help thinking we'll make more progress if we apply the patch to
> > > > > > > HEAD now.  We'll get wider visibility of problems with the new code -
> > > > > > > and there are likely issues beyond the performance problems that have
> > > > > > > been the focus so far - and more people will see the benefit of Tony
> > > > > > > (and Aleksey's) hard work in getting us to this point.
> > > > > > >
> > > > > > > I certainly don't want all this work to be completed outside svn HEAD
> > > > > > > and committed a week or two before the freeze for next milestone.
> > > > > > >
> > > > > > > Regards,
> > > > > > >  Mark.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tony Wu
> > > > > > China Software Development Lab, IBM
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Tony Wu
> > > > China Software Development Lab, IBM
> > > >
> > >
> >
> >
> > --
> > Tony Wu
> > China Software Development Lab, IBM
> >
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>


-- 
Tony Wu
China Software Development Lab, IBM