On 2/7/08, Alexey Petrenko <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> wrote: > > > Thanks very much, so we got 4MB src code cutted w/o pay. Cheer! > > > > > > On 1/23/08, Aleksey Shipilev <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 14 January 2008 at 16:21, Tim Ellison <[EMAIL PROTECTED]> > > > > > > > > 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
