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 <[EMAIL PROTECTED]>: > 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. >
