harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib]remove the duplicate locale data
Date Sat, 09 Feb 2008 21:56:04 GMT
Good work Tony.  Perhaps a wiki page or umbrella JIRA would help us 
track these?  I think they may get lost in mail discussion.

Just my 2c.

Tony Wu wrote:
> 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.
>>>>>> 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
>>>>>> 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
>>>>>>> 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
>>>>>>> correct it just because the bad version has better performance.
>>>>>>> performance is nothing if there is no correctness.
>>>>>>> Secondly, we adopt ICU through delegation which involves extra
>>>>>>> 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
>>>>>>> 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
>>>>>>> required. Actually only I myself am working on the development
>>>>>>> (Surely, Aleksey is very helpful on testing), this synchronization
>>>>>>> might be a nightmare to me. Furthermore, the code on branch will
>>>>>>> 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
>>>>>>> with himself whenever he wants to contribute?
>>>>>>> On 1/15/08, Mark Hindess <mark.hindess@googlemail.com>
>>>>>>>> On 14 January 2008 at 16:21, Tim Ellison <t.p.ellison@gmail.com>
>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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

View raw message