Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of vstrigun@gmail.com designates
 64.233.166.180 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=UFhDzcSpxR0WrpztAMOZf74MUOG/3a83tfk3BDcR7a9QLChfCwRJH5X1BIr06DJi+MQj3dhtXhT4COZa4MSEGkps3Cq4eSDE5GkYkPrhr+NtfzIdj26K1n9fjJDJ+Z4PD6juFq4bkZXce/c3ThGikOUV3ZdTs9skpmkP38Adt/E=
Message-ID: <e3b630230704090408o7965ff3dm890ce3196bd0ba83@mail.gmail.com>
Date: Mon, 9 Apr 2007 15:08:20 +0400
From: "Vladimir Strigun" <vstrigun@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [contribution] Contribution of charset encoders/decoders for
 NIO_CHAR module
In-Reply-To: <2A786EB15713B544AB79607529273B049CDCB8@mssmsx411>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <211709bc0704090249i3bf4babu4f3f5678b1d0c1e8@mail.gmail.com>
	 <2A786EB15713B544AB79607529273B049CDCB8@mssmsx411>

On 4/9/07, Volynets, Vera <vera.volynets@intel.com> wrote:
> Hi,
> there is one small point about our independence from icu.
> Vm uses icu4c during classfile parsing. It would be great if we have the
> same functionality and don't use icu4c.
> Do you work on it?

Vera,

With the new bundle we still dependent on ICU. No, I'm not working on
replacement for icu4c.

Thanks.
Vladimir.


> WBR,Vera!
>
> -----Original Message-----
> From: Tony Wu [mailto:wuyuehao@gmail.com]
> Sent: Monday, April 09, 2007 1:50 PM
> To: dev@harmony.apache.org
> Subject: Re: [contribution] Contribution of charset encoders/decoders
> for NIO_CHAR module
>
> I wonder if it is possible to make it as built-in charset provider and
> make icu as an extension?
>
> On 4/9/07, Tony Wu <wuyuehao@gmail.com> wrote:
> > amazing work.
> > generating the charsets...
> >
> > On 4/9/07, Vladimir Strigun <vstrigun@gmail.com> wrote:
> > > On 4/9/07, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> > > > On 4/9/07, Vladimir Strigun <vstrigun@gmail.com> wrote:
> > > > >
> > > > > On 4/9/07, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> > > > > > Super cool!!!
> > > > > > Does it mean we're not dependent on ICU any more?
> > > > >
> > > > > Unfortunately not all charsets supported with attached bundle.
> The
> > > > > list of supported charsets you could find in README file.
> > > >
> > > >
> > > > Hi Vladimir, not unfortunately at all. :)
> > > >
> > > > We're on the way to be independent of ICU, right? ;)
> > >
> > > Yes, you right,  we're on the way :)
> > >
> > >
> > > > > On 4/9/07, Vladimir Strigun <vstrigun@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi all!
> > > > > > >
> > > > > > > I'm happy to announce one more contribution to harmony on
> behalf of
> > > > > > > Intel. Provided implementation of charset encoders/decoders
> is
> > > > > > > intended to replace the ICU-based charsets encoding/decoding
> > > > > > > operations. The code was developed in clean-room environment
> inside
> > > > > > > Intel and I'd like you to play with it and include to
> current Harmony
> > > > > > > tree.
> > > > > > >
> > > > > > > The package could be found there:
> > > > > > > HARMONY-3593
> > > > > > >
> > > > > > > The algorithms for charsets encoding/decoding differs from
> that of
> > > > > > > ICU, all charsets are generated from current Harmony or any
> other
> > > > > > > implementation of Java and could be properly integrated into
> current
> > > > > > > nio_char module. The archive contains source files for 6
> charsets:
> > > > > > > GB18030, US-ASCII, ISO-8859-1, UTF-8, UTF-16, UTF-16BE,
> UTF-16LE;
> > > > > > > implementation of CharsetProvider; generator for other
> Charsets and
> > > > > > > native part. I've tested the package with more that 90
> charsets, and
> > > > > > > all benchmarks and tests passed with new bundle.
> Additionally I have
> > > > > > > significant boost for Dacapo.antlr and Dacapo.xalan
> benchmarks with
> > > > > > > current Harmony tree on DRLVM and IBM VM. On DRLVM I have
> 2.5x boost
> > > > > > > for antlr and ~5-8x for xalan.
> > > > > > >
> > > > > > > The main advantages of the package are the following:
> > > > > > >   - Code for every charset is generated by CharsetGenerator,
> thus, if
> > > > > > > some modification would be necessary we need just correct
> generator
> > > > > > > and re-generate all sources.
> > > > > > >   - We use 2 different encoders and decoders for java and
> direct
> > > > > > > buffers. Since most applications use java heap buffers,
> unlike
> > > > > > > existing implementation it doesn't produce lots of native
> calls to
> > > > > > > perform encoding/decoding operations on the java buffers
> those
> > > > > > > significantly improving performance. This is the main reason
> why we
> > > > > > > have such a significant boost for Dacapo.
> > > > > > >   - Charset tables for encoding/decoding are stored in
> appropriate
> > > > > > > classes.
> > > > > > >
> > > > > > > Since the package contains implementation for 6 charsets
> only,
> > > > > > > documentations how to generate and build additional charsets
> you could
> > > > > > > find in README file from contributed package.
> > > > > > >
> > > > > > > Please do not hesitate to contact me for more details.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Vladimir.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Andrew Zhang
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew Zhang
> > > >
> > >
> >
> >
> > --
> > Tony Wu
> > China Software Development Lab, IBM
> >
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>