Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 26700 invoked from network); 9 Apr 2007 09:30:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Apr 2007 09:30:22 -0000 Received: (qmail 55360 invoked by uid 500); 9 Apr 2007 09:30:26 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 55028 invoked by uid 500); 9 Apr 2007 09:30:25 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 55019 invoked by uid 99); 9 Apr 2007 09:30:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Apr 2007 02:30:25 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of vstrigun@gmail.com designates 64.233.166.182 as permitted sender) Received: from [64.233.166.182] (HELO py-out-1112.google.com) (64.233.166.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Apr 2007 02:30:18 -0700 Received: by py-out-1112.google.com with SMTP id p76so1010694pyb for ; Mon, 09 Apr 2007 02:29:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LbS7a5dPDjup7+S0C94JbdFlbSrgP6MUOMbDKm3yWv44QP0BidRzpaGUuRy6W69wGyYxmzL6RbVQfIzDzZIdsTRd1heKKN2gUlBB+JGx2UXJib4IbHfajhE42THMVYuf7kVn2rdIm4objcQtWpIy1tdxuPLJqBFHOlf48Fnu6kQ= 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=Q6SEkD8W9udzgtdohWA3WG8z3CPBbQ7DFG0U+O89taQudePnloOFqAiXSXnlsvVgAt1XJ0SLUuSMayNmwx32NFSKQpTbKEljy2LhC+bp5JO54RknK0r30plIxxOP8HMEnOrgR68KNMpuWEWqX/ciDqtxWefBnzrhx9uX0ndW6nw= Received: by 10.35.99.17 with SMTP id b17mr10945605pym.1176110997772; Mon, 09 Apr 2007 02:29:57 -0700 (PDT) Received: by 10.35.52.19 with HTTP; Mon, 9 Apr 2007 02:29:57 -0700 (PDT) Message-ID: Date: Mon, 9 Apr 2007 13:29:57 +0400 From: "Vladimir Strigun" To: dev@harmony.apache.org Subject: Re: [contribution] Contribution of charset encoders/decoders for NIO_CHAR module In-Reply-To: <4d0b24970704090219u23b02f3ap88cd05665a12c004@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d0b24970704090154k25065989q62a2e0b66fc525aa@mail.gmail.com> <4d0b24970704090219u23b02f3ap88cd05665a12c004@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On 4/9/07, Andrew Zhang wrote: > On 4/9/07, Vladimir Strigun wrote: > > > > On 4/9/07, Andrew Zhang 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 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 >