harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject Re: [drlvm] log4cxx vs custom logger Re: [general] icu or apr-iconv, which coding library is better?
Date Mon, 14 Apr 2008 17:43:19 GMT
I support the idea of lightweight logger, as we actually do not use
many of log4cxx features.
I also think it would be worth to get rid of log4cxx dependencies.

On the other hand, I agree with Alexey: we should ensure that the
functionality of the new logger is enough for our purposes. And
somebody should support this new code...

Thanks,
Ilya.

2008/4/14, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> I personally support to have a custom logger. Maybe it is just
>  personal taste that, when I write SW, I always try to keep the code
>  limited to what is needed, and I don't want the SW to have too many
>  unnecessary external dependences. And, my experience with log4cxx was
>  not very pleasant. :(
>
>  Thanks,
>  xiaofeng
>
>
>  On Mon, Apr 14, 2008 at 6:49 PM, Alexey Varlamov
>  <alexey.v.varlamov@gmail.com> wrote:
>  > 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
>  >  >
>  >
>
>
>
>
> --
>  http://xiao-feng.blogspot.com
>

Mime
View raw message