harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Wed, 10 Oct 2007 03:28:54 GMT
On 10/9/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Tony Wu wrote:
> > On 10/8/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> >
> >> Tony Wu wrote:
> >>
> >>> Sorry for reply late, just recover from national holiday.
> >>>
> >>>
> >> No problem :)
> >>
> >>
> >>> About the performance issue, native code is faster but jni call is
> >>> heavy. So, icu4j 3.4 is good at encoding/decoding several bytes
> >>> whereas icu4jni3.4 is good at handling thousands bytes. Bidi is
> >>> another story, I'll try to compare the native impl and java impl later
> >>> in 3.8.
> >>>
> >> Thanks Tony - it will be interesting to know how pure Java ICU performs
> >> within Harmony compared to the current setup. If it helps I can open a
> >> JIRA for moving to ICU4J 3.8 and attach a basic patch to eliminate the
> >> need for icu4jni/icu4c to get you started.
> >>
> > ok. we may need change the code in both DRLVM and j9 since the lib of
> > icu4c is directly refered by them.
> >
>
> Yes - In [1] Pavel mentioned that DRLVM uses ICU4C for some tasks. I
> think, as Pavel later suggests [2], we could move the ICU4C libraries to
> the DRLVM repository when they are no longer required by classlib and
> raise a JIRA for further discussion as to whether we want to remove this
> dependency for DRLVM also or keep ICU4C and upgrade to 3.8.
>
agree.

> J9's dependency on the ICUInterface dll is purely a dllload() call so
> that the library is initialised before use by the class library. I
> believe this can be easily worked around with the current J9 VME by
> simply having a dummy dll in jre/bin for it to load.
>
would you pls help to build a new J9 VME for this purpose :)
> >
> >> Are there any particular
> >> benchmarks you had in mind for this?
> >>
> >>
> > ya, there is a micro benchmark on HARMONY-3709
> >
>
> Thanks Tony - Ill take a look.
>
> >
> >>> Anyway, it is worth to do some work to remove the 10m
> >>> dependency(icu4c).
> >>>
> >>> BTW, We keep some resource bundle classes in luni, such as Locale and
> >>> Currency, which used by luni and text module. These data are aslo
> >>> included in icu, I suggest to remove this overlap, just keep one of
> >>> them.
> >>>
> >> Agreed - if we can use the ICU version of these resources then IMHO we
> >> should do it.
> >>
> >>
> > I've successfully changed the data in luni but got some problem in
> > text, since the organization in resource bundle for locale is
> > different from each other. And unfortunately there is no doc in
> > current harmony impl, I need some time to try and guess them.
> >
>
> Which data in luni have you moved to the ICU versions? There is some
> conversation in another branch of this thread [3] about keeping Harmony
> versions of charsets - is that relevant to what you're looking at?
>
Sorry I should have clarified that it's not about charsets. I
delegated all the classes which depends on their internal resoure
bundle data in luni to ICU's impl, so that we can remove all the
classes in removed the package org/apache/harmony/luni/internal/locale
later. That will get 2 mega bytes decrease form harmony source code.

> Regards,
> Oliver
>
> [1]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200710.mbox/%3ce0f125db0710010352r251b0f1dt2080e8d41b849bcc@mail.gmail.com%3e
> [2]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200710.mbox/%3ce0f125db0710010818o4af7073fibe0f6a1222de6dff@mail.gmail.com%3e
> [3]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200710.mbox/%3c2c9597b90710090458v44aa7c07q48e5bee3898a582c@mail.gmail.com%3e
>
> >
> >> Regards,
> >> Oliver
> >>
> >>
> >>> A good news is that icu3.8 providers a data customization
> >>> tool[1], I've tried it and reported a failure when customizing icu4j.
> >>>
> >>> [1]http://apps.icu-project.org/datacustom/
> >>>
> >>>
> >>> On 10/2/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> >>>
> >>>
> >>>> Hi Alexei,
> >>>>
> >>>> Yes, performance is an issue here. I would envisage that for
> >>>> small/medium icu jobs we will see a performance increase due to calls
> >>>> into icu C code via jni adding an overhead. For larger conversion jobs
> >>>> we may find that icu4c/icu4jni provide better results. Clearly this
is
> >>>> something that needs to be weighed up against the pros of moving to
> >>>> using a purely Java implementation. Are there any tests you might
> >>>> suggest to make a performance comparison?
> >>>>
> >>>> I see Tony has spoken to the icu developers before about this issue
[1].
> >>>> Do you have any input Tony?
> >>>>
> >>>> Regards,
> >>>> Oliver
> >>>>
> >>>> [1] http://www.nabble.com/From-icu4jni-to-icu4j-t3543140.html
> >>>>
> >>>> Alexei Zakharov wrote:
> >>>>
> >>>>
> >>>>> Hi Oliver and all,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> The first thing is that icu4jni is no longer supported from
this release
> >>>>>> onwards. The icu4jni api have been incorporated into icu4j and
are
> >>>>>> implemented in pure Java now.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Secondly, the Bidi class has also been implemented fully in
icu4j now,
> >>>>>> so it is possible for us to also drop icu4c as a dependency
and use pure
> >>>>>> icu4j for this functionality.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> I have no objections. Only like to be sure we won't get significant
> >>>>> performance degradation by moving from native implementation to
pure
> >>>>> Java.
> >>>>>
> >>>>> Thanks,
> >>>>> Alexei
> >>>>>
> >>>>> 2007/10/1, Oliver Deakin <oliver.deakin@googlemail.com>:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I have been looking recently at what it would take for us to
step up to
> >>>>>> icu4j 3.8 and thought I would give everyone a heads up on what
I have
> >>>>>> discovered.
> >>>>>>
> >>>>>> The first thing is that icu4jni is no longer supported from
this release
> >>>>>> onwards. The icu4jni api have been incorporated into icu4j and
are
> >>>>>> implemented in pure Java now.
> >>>>>> Secondly, the Bidi class has also been implemented fully in
icu4j now,
> >>>>>> so it is possible for us to also drop icu4c as a dependency
and use pure
> >>>>>> icu4j for this functionality.
> >>>>>>
> >>>>>> The major advantage I see of moving to pure icu4j 3.8 is that
we no
> >>>>>> longer need to maintain prebuilt binaries of the icu4c and icu4jni
> >>>>>> libraries across all platforms in our repository. This simplifies
the
> >>>>>> process of upgrading to new versions of icu and also allows
us to move
> >>>>>> to new platforms with greater ease.
> >>>>>>
> >>>>>> I am currently testing a patch to switch over to icu 3.8 and
completely
> >>>>>> remove the need for icu4c/jni. I have discovered a couple of
bugs in the
> >>>>>> new Bidi functionality [1] which I have raised on the icu dev
list and
> >>>>>> are in the process of being fixed. I hope that once they are
all
> >>>>>> resolved we will be able to pick up a patched icu4j 3.8 jar
for our use.
> >>>>>>
> >>>>>> Im interested to hear if anyone has any comments/objections
to this?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Oliver
> >>>>>>
> >>>>>> [1]
> >>>>>> http://bugs.icu-project.org/trac/ticket/5952
> >>>>>> http://bugs.icu-project.org/trac/ticket/5961
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Oliver Deakin
> >>>> Unless stated otherwise above:
> >>>> IBM United Kingdom Limited - Registered in England and Wales with number
741598.
> >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >> --
> >> Oliver Deakin
> >> Unless stated otherwise above:
> >> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> >>
> >>
> >>
> >
> >
> >
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message