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 alexey.v.varlamov@gmail.com
 designates 74.125.46.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=fXjJe5lEaWFZK0RWj1WxBUIVWdZVt51RfxD4Dt85HlLLXrOBIJdysUkic5WeiZrsHfw40NzzCxNkgW4Rh3DGy+/4uu6OXbTy9qYwbTMyT+Q7byL0gqSfZZ7Au22amZ6WUyjTbJqLIO5wDSy23xrokeni+K9LfHy60sJNJ6zk/GA=
Message-ID: <f944d83d0804140349m24859d0ej3d14fa5496115401@mail.gmail.com>
Date: Mon, 14 Apr 2008 17:49:58 +0700
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: dev@harmony.apache.org
Subject: [drlvm] log4cxx vs custom logger Re: [general] icu or apr-iconv,
 which coding library is better?
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Folks,

I suggest we avoid subject screening and discuss the main issue
purposefully: what functionality do we need from VM logging and
whether it worths to replace log4cxx with custom lightweight impl (see
HARMONY-5692).
Main points:
- log4cxx is very powerful and highly customizable facility, it
provides control over log output at arbitrary granularity (literally,
any category with any logging level may be independently output to
different (mulltiply) destinations (file, socket, DB, etc) in
arbitrary format), supports logs rotations, config files etc.
- log4cxx is relatively costly: draws extra external dependencies,
increases binary weight of VM (how much for _release_ build, BTW?),
needs certain integration level.
- most of the log4cxx features and flexibility are not really used at
the moment (yet might appear invaluable for remote debugging or
maintenance).
- few features of Invocation API (vfprintf/exit/abort hooks) are not
supported in current log4cxx integration (should not be too hard to
add).
- the small logger, suggested by Alexei F, gives those features of
Invocation API for free and reduces dependency constraints for potrlib
(I think performance wins are negligible).

So, do we want to exchange feature-rich but heavy LOG4CXX for small
and compatible logger (and more freedom to choose a VM portlib)?

I personally have no principal objections for the suggested
replacement, just want to ensure the simple logger is functional
enough and supports most important usecases (I listed them in the
JIRA).

Regards,
Alexey


2008/4/14, Alexei Fedotov <alexei.fedotov@gmail.com>:
> 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
>