Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of wuyuehao@gmail.com designates
 209.85.128.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z12V4YI86f8mezM1fU0ZXOGxicrpflFVg+2ToiRJM1RsdF+dnZ4e/bDm90+LuYWF9OHDPyouAJKPgn6DrGpALyLg77P1EauAKAbsk2+ADxglEPNnyacEUmjPkQEx9QRd0A77SNrysXVAPwF8qzLKCKKISIr/Pjx1wTh7PPZaWIs=
Message-ID: <211709bc0711162259m3e054ae7j8aad856405a31bab@mail.gmail.com>
Date: Sat, 17 Nov 2007 14:59:58 +0800
From: "Tony Wu" <wuyuehao@gmail.com>
To: dev@harmony.apache.org
Subject: Re: Problems with migration to new ICU, r592434 & r593469
In-Reply-To: <c3755b3a0711160829t221ccc77yc08b9d20b354b30f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <253b20230711160740h71b90e5fv1b16614b56ebd2@mail.gmail.com>
	 <c3755b3a0711160829t221ccc77yc08b9d20b354b30f@mail.gmail.com>

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