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 alexei.fedotov@gmail.com
 designates 209.85.146.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=i9bprrxpNwle/UCiawNvCKbsDB+Bx1xxqQOTfVJ/8oHczDW28z97pr4BBOaDoGWaubIso4ITqJSGtHhUeD6jSB0ym/BDzhxdrgiK3minuso1zKK+HYOAGi5GcBnzxseOnGs1AUuM6nT2J9FwaUkgre+Q7e2oXT6Vp/H8yclPJ8g=
Message-ID: <c30d70960804150340o575737e5kb9f9da25f8145662@mail.gmail.com>
Date: Tue, 15 Apr 2008 14:40:40 +0400
From: "Alexei Fedotov" <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] icu or apr-iconv, which coding library is better?
In-Reply-To: <c30d70960804132126s35cb22a5y976c854e35ca3a19@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c30d70960804112037g4e704fe8mf459554393f39fe9@mail.gmail.com>
	 <3b3f27c60804121330v4a30a1f9rf7662e017bc9c975@mail.gmail.com>
	 <c30d70960804130217w7ecfeb3ag545358e3e54ac0c6@mail.gmail.com>
	 <3b3f27c60804131939k381c403fg5ec084b667c094f3@mail.gmail.com>
	 <c30d70960804132126s35cb22a5y976c854e35ca3a19@mail.gmail.com>

Nathan,
Could you please tell if you still have concerns about HARMONY-5692?

Thanks, Alexei

On Mon, Apr 14, 2008 at 8:26 AM, Alexei Fedotov
<alexei.fedotov@gmail.com> wrote:
> Hello Nathan,
>  Thanks for your tough questions.
>  1.
>  I'm sorry for using "red herring". I honestly believe that having two
>  charset coding libraries is overkill and a good reason to throw one of
>  them away.
>
>  2.
>  Here is a JNI specification [1]. Please, check a table below
>  JNI_CreateJavaVM description. It describes how VM logging is
>  initialized. This was not implemented in DRLVM, and is implemented in
>  [2].
>
>  3.
>  A big chunk of removed functionality is logging into separate files.
>  To my perception, this is not a frequent use case. The original reason
>  why original DRLVM engineers attached log4cxx to my original C/C++
>  DRLVM logger was our attempt to achieve "Apache synergy".
>
>  4.
>  You asked for an anecdotal proof of the fact why smaller executables
>  may run faster. I have just invented one: smaller executables better
>  fit into a processor cache, produce less cache misses and hence
>  decrease a bus load. For a particular case this should be measured,
>  and I don't have solid data yet.
>
>  5.
>  There is one more argument which actually forced me to start thinking
>  into this direction: my shmmap component (a hybrid of shm and mmap)
>  was originally developed as a part of aprutil (because it is based on
>  apr_shm and apr_mmap). We already have four porting libraries: port,
>  portlib, apr and aprutil in Harmony. Removing one which is not tightly
>  coupled with other parts make it easier for people like me to decide
>  where it is natural to place our hand-made components.
>
>  More questions? Suggestions?
>
>  [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html
>  [2] https://issues.apache.org/jira/browse/HARMONY-5692
>
>
>
>
>  On Mon, Apr 14, 2008 at 6:39 AM, Nathan Beyer <nbeyer@gmail.com> wrote:
>  > On Sun, Apr 13, 2008 at 4:17 AM, Alexei Fedotov
>  >
>  > <alexei.fedotov@gmail.com> wrote:
>  >
>  > > Hello Nathan,
>  >  >  Thanks for questions.
>  >  >
>  >  >  There are many other places where charset (en/de)coders are used, but
>  >  >  we use icu4c there.
>  >
>  >  I know, but your original post made it sound like this was the big
>  >  reason for accepting this patch, but charset codec usage was a red
>  >  herring - I really don't like it when people use such tactics. Focus
>  >  on the real issue, please.
>  >
>  >
>  >
>  >  > HARMONY-5692 is a replacement of log4cxx with
>  >  >  custom logger and removing dependent aprutil and apr-iconv which are
>  >  >  not used any longer after this replacement.
>  >  >    * The replacement decreases
>  >  >  windows_x86_msvc_debug/deploy/jdk/jre/bin/default/harmonyvm.dll size
>  >  >  from 4079616 to 2961408. This would probably improve a startup time.
>  >
>  >  Any proof, even anecdotal to this claim?
>  >
>  >
>  >  >    * The custom logger requires less lines of code than a log4cxx
>  >  >  wrapper, hence, is easier to maintain.
>  >  >    * By specification VM logging should be done using provided
>  >  >  vfprintf. C++ logger adds two layers of conversion. vfprintf layer wan
>  >  >  not implemented, and implementing it would increase a number of
>  >  >  wrappers for log4cxx.
>  >
>  >  Can you point to this bit of the specification? I don't understand the
>  >  last bit of what you're claiming. There's a wrapper that doesn't
>  >  exist, but needs to?
>  >
>  >
>  >  >
>  >  >  Please, let me know if these arguments are enough for log4cxx being removed.
>  >
>  >  No, they aren't for me. The original DRLVM engineers used log4xx for a
>  >  reason, what functionality are we giving up?
>  >
>  >
>  >
>  >  >
>  >  >  Note, apr itself remains, and it is pretty good piece of code to my
>  >  >  perception. I do not intend to invent pools or OS call wrappers. We
>  >  >  throw away the staff guys from apr does not allow to put into their
>  >  >  main module. :-)
>  >  >  Thanks.
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >  On Sun, Apr 13, 2008 at 12:30 AM, Nathan Beyer <nbeyer@gmail.com> wrote:
>  >  >  > Huh? This post doesn't sound like anything in HARMONY-5692. We need
>  >  >  >  clear somethings up first.
>  >  >  >
>  >  >  >  1. apr-iconv is in the build as a dependency of log4cxx
>  >  >  >  2. there is no use of apr-iconv for charset encoding/decoding
>  >  >  >  3. HARMONY-5692, AFAIU is replacement of log4cxx with custom logger
>  >  >  >  implementation to reduce the build time
>  >  >  >
>  >  >  >  What's the value of replacing log4cxx with a custom logger? Reducing
>  >  >  >  the build time isn't enough for me - there have to be other ways to
>  >  >  >  accomplish that without sub-system replacement.
>  >  >  >
>  >  >  >  -Nathan
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >  On Fri, Apr 11, 2008 at 10:37 PM, Alexei Fedotov
>  >  >  >  <alexei.fedotov@gmail.com> wrote:
>  >  >  >  > Hello,
>  >  >  >  >
>  >  >  >  >  One may notice that both icu and apr-iconv are currently used to build
>  >  >  >  >  Harmony HDK. Both libraries address charset encoding and decoding.
>  >  >  >  >  Should we keep both of them or try to use the only one?
>  >  >  >  >
>  >  >  >  >  HARMONY-5692 [1] contains one possible "compilable" answer to this
>  >  >  >  >  question and related reasoning. Alexey Varlamov and Tim suggested
>  >  >  >  >  discussing the matters on dev@ list, so I created this thread on the
>  >  >  >  >  subject. You are welcome to share your opinion about the libraries
>  >  >  >  >  Harmony depends on, the patch from [2], my arguments defending the
>  >  >  >  >  patch, and further directions here.
>  >  >  >  >
>  >  >  >  >  --
>  >  >  >  >  With best regards,
>  >  >  >  >  Alexei
>  >  >  >  >
>  >  >  >  >  [1] https://issues.apache.org/jira/browse/HARMONY-5692
>  >  >  >  >
>  >  >  >
>  >  >
>  >  >
>  >  >
>  >  >  --
>  >  >  With best regards,
>  >  >  Alexei
>  >  >
>  >
>
>
>
>  --
>  With best regards,
>  Alexei
>


-- 
With best regards,
Alexei