harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Sun, 18 Nov 2007 03:25:39 GMT
FYI.
Following commits are reverted at r596044.
593469 fix the regression that we have different locale data for
Europe/London, along with some fixes for other difference against RI
593024 Fix a bug that SimpleDateFormat.parse does not reload the latest timezone
592434 Apply patch Harmony-5061 which removes the duplicate locale data

On 11/17/07, Tony Wu <wuyuehao@gmail.com> wrote:
> On 11/17/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > To be clear all these issues are not from migrating from previous
> > version of ICU to 3.8. But from removing Harmony code which duplicates
> > ICU code.
> > So we actually need to fix ICU not Harmony to get our performance and
> > other behaviors back. And the problem here could be that we are not
> > ICU and we do not have ICU committers, at least as far as I know. Thus
> > we can not be sure that needed patches will be integrated ASAP even if
> > we will create all needed patches our selves.
> yes.
> >
> > Moreover some patches can contradict with ICU vision. For example
> > HARMONY-5085. The problem there that the Harmony method starts to
> > return array of ICU classes instead of array of Harmony J2SE public
> > API classes. Array scanning with ICU -> Harmony classes conversion
> > will degrade performance. So the only way here to fix ICU to return
> > public api classes instead of ICU classes. And I'm not sure that ICU
> > project will be ready to integrate such a changes.
> It is not easy for both them and us.
> >
> > From the other hand I agree that we do not want to reinvent the wheel
> > and keep and support all this internationalization stuff in Harmony if
> > we can delegate it to another suitable project. But this project need
> > to fit Harmony needs :)
> To my knowledge, we have no alternative project except ICU :)
>
> >
> > I suggest the following as a result...
> > 1. Revert the patch which removes Harmony code which duplicates ICU.
> > 2. File all the found issues to ICU database.
> > 3. Create as much patches for ICU to fit Harmony needs as we can and
> > provide them to ICU.
> > 4. Wait until all these patches will be integrated and new ICU release come.
> > 5. Remove ICU duplicating functionality again.
> >
> > Thoughts? Objections?
> I've thought about the reverting. Basically I agree to reverting this
> patch for the coming milestone. I will record what I have modified and
> revert it soon.
>
> Still I have some concern and want to discuss with you here. We have
> to face some problem which can not be deracinated even if I recommit
> the patch at the beginning of next iteration.
>
> One of them is about implementation detail which may contradict to
> ICU's vision as you mentioned on Harmony-5085.
>
> Another is the performance degradations. I'm afraid that we will
> suffer from the delegation even if ICU has no performance issue
> itself.
>
> As I talked in another thread, the perfect solution is that ICU could
> contribute their implementation against java SE API to harmony
> directly. But I think we have a long way to go to achieve it.
>
> Meanwhile I suggest setting up some infrastructure on performance.
> First, we can have a baseline and try to improve step by step based on
> it. Then we could notice the degradation immediately when it happens.
> Furthermore, we can get the detail whenever we want to analyze it.
> (Sorry if there is one existing and I did not notice.)
>
> >
> > Thanks in advance.
> >
> > SY, Alexey
> >
> > 2007/11/16, Sergey Kuksenko <sergey.kuksenko@gmail.com>:
> > > Hi All,
> > >
> > > I'd like to continue discussion about migration to new ICU which was done by
> > > r592434 & r593469 commits.
> > > This migration is a big deal and it should be done in any case.
> > > However, after migration we got a set of problems like a set of failures and
> > > performance degradations.
> > > Some of the failures were already fixed, some of them are noticed on
> > > http://wiki.apache.org/harmony/MigrateToICU ,some of them are noticed in
> > > JIRA like (https://issues.apache.org/jira/browse/HARMONY-5085) and I am
> > > afraid that some of them are not yet detected.
> > > Performance degradation you can see in JIRAs (
> > > https://issues.apache.org/jira/browse/HARMONY-5129 &
> > > https://issues.apache.org/jira/browse/HARMONY-5122)
> > > In general we may conclude that performance of SPECjbb2005 with DRLVM
> > > decreased by 20%.
> > > Moreover, according our results, performance of application servers measured
> > > with EAStress degraded 3x times!!!
> > > Also, there are a lot of small tests which can show degradation.
> > >
> > > And the key problem here that we have no so much time before code freeze in
> > > December and it is not good to have new milestone release worse then
> > > previous.
> > > *I suggest to roll back ICU migration till the end of current milestone.*
> > > Let's apply these patches exactly after beginning of the next milestone and
> > > will work on all stability and performance problems together in next
> > > milestone. I hope in that case we will have more time and tune new ICU more
> > > efficiently.
> > >
> > >
> > > --
> > > Best regards,
> > > ---
> > > Sergey Kuksenko.
> > > Intel Enterprise Solutions Software Division.
> > >
> >
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message