harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Tue, 09 Oct 2007 15:18:07 GMT
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.

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.

>   
>> 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?

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


Mime
View raw message