harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib]remove the duplicate locale data
Date Wed, 06 Feb 2008 17:10:37 GMT
On 2/7/08, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> I would suggest to mark these issues as "must be fixed before M5"
> since Harmony M5 should not be worse then M4.
>
> SY, Alexey

Hi, Alexey

Why do you think these differences are so important, do you have some
application which is blocked by some of them. I want to know which one
has higher priority.

I don't think they are so significant as to be considered as a
regradation. Actually they are different form of represtation rather
than incorrect behavior. And please do not think all the differences
against RI are bugs, I've claimed that ICU3.8 uses the CLDR 5.0 which
is much newer than RI. That is to say, the contry code, timezone name,
offset, etc. is up to date in Harmony and outdated in RI. And the
outdated data in this area does no make any sense.

As last, I have to say sorry for that I can not take action
immediately since today is Spring Festival in China, I must spend my
time with family. Don't worry, I can give you my word that I can fix
all of them before M5.

>
> 2008/2/6, Pavel Pervov <pmcfirst@gmail.com>:
> > Tony,
> >
> > Unfortunately, I have a number of JIRAs for you. They all are
> > regressions after removing duplicate locale data.
> >
> > Here they go:
> >
> > https://issues.apache.org/jira/browse/HARMONY-5459
> > https://issues.apache.org/jira/browse/HARMONY-5461
> > https://issues.apache.org/jira/browse/HARMONY-5465
> > https://issues.apache.org/jira/browse/HARMONY-5466
> > https://issues.apache.org/jira/browse/HARMONY-5467
> > https://issues.apache.org/jira/browse/HARMONY-5468
> > https://issues.apache.org/jira/browse/HARMONY-5469
> >
> > 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

Mime
View raw message