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 <[EMAIL PROTECTED]> 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 <[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 > -- With best regards, Alexei
