harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Fri, 16 Nov 2007 16:29:07 GMT
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.

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.

>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 :)

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?

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.

View raw message