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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> wrote: > > > On Sun, Apr 13, 2008 at 4:17 AM, Alexei Fedotov > > > > > > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 > > > > > <[EMAIL PROTECTED]> 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
