My claim is based on day-to-day observations of hundreds of JVMs under various load scenarios.
Your claim that modern JVMs "do escape analysis" is worthless as it shows that you have merely read some blog posts, and even those you've read only partially. Please point to the exact lines of code in hotspot or any other modern jvm that will optimize the specific lazy evaluation example you presented, together with the opto-assembly that their JITs produce. Failing that, take your attitude elsewhere. On Thu, Mar 22, 2012 at 8:49 PM, Ximin Luo <infini...@gmx.com> wrote: > The "drastically cleaner syntax" is a red herring. Most of the time when > you > are doing a complex calculation, you are not going to put it on one line > anyway. In such cases, the function you are using to do the calculation > might > as well be the toString() method of some object. > > Your claim of "double-digit millisecond" pauses is worthless without some > benchmarking and actual numbers. Modern JVMs do escape analysis to avoid > heap > allocation and this helps especially for transient computations like in > logging. > > On 22/03/12 21:59, Zlatin Balevsky wrote: > > Double-digit millisecond pauses are not nothing. They may be acceptable > right > > now but unless you can offer a drastically cleaner syntax Fred should > stick > > with predicates as they are handled much better by the hotspot jit. > > > > On Mar 22, 2012 5:36 PM, "Ximin Luo" <infini...@gmx.com > > <mailto:infini...@gmx.com>> wrote: > > > > Lazy evaluation is trivial. > > > > Log.info("{1} did {2}", > > new Object(){ public String toString() { return ITEM_1; } }, > > new Object(){ public String toString() { return ITEM_2; } } > > ); > > > > Garbage collection with short-lived objects costs next to nothing. > > > > On 22/03/12 21:15, Zlatin Balevsky wrote: > > > Constructing the logging strings is half of the problem. The > amount of > > garbage > > > they will generate will result in significantly more time in > garbage > > collection > > > pauses. > > > > > > Unless you figure out a way to mimic lazy evaluation you have to > live > > with the > > > isLoggable predicates. varargs are not an option either because > they also > > > create garbage. > > > > > > On Mar 22, 2012 8:11 AM, "Marco Schulze" < > marco.c.schu...@gmail.com > > <mailto:marco.c.schu...@gmail.com> > > > <mailto:marco.c.schu...@gmail.com <mailto: > marco.c.schu...@gmail.com>>> wrote: > > > > > > > > > > > > On 22-03-2012 08:50, Matthew Toseland wrote: > > > > > > On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote: > > > > > > There are basically two big concerns regarding logging > in fred: > > > > > > - Readability and code clutter, which was my original > > questioning; > > > - Raw throughput, as raised by toad. > > > > > > Point 1 could mostly be solved by removing any traces > of > > logMINOR and > > > logDEBUG on all but the few places where generating > messages > > to be > > > logged brings noticeable slowdown. That'd be enough, > but, > > personally, > > > the mess that the logging backend is does warrant a > replacement. > > > According to toad, the current system needs > log{MINOR,DEBUG} to > > > function > > > in a timely manner. Based on this, I think we all > agree a > > > replacement is > > > desirable. > > > > > > Logging has a few additional requirements: > > > > > > - Log rotation (possibly live); > > > - Reentrant; > > > - Per-class filtering; > > > - Specific information in log (class-name, for > example). > > > > > > Now, _any_ library which fits would make me happy, as > long as > > they > > > agree > > > to two points: > > > > > > - Either lightweight or with optional features. Else, > it > > would only > > > transfer bloat to freenet-ext.jar. For example: > log2socket, > > config > > > management and multiple logging instances; > > > - Implementable in a few LoC. Specially, it shouldn't > need > > specialized > > > Formatter and Writer. > > > > > > Plus, it should be fast. > > > > > > From the quick research I made (yep, too many lists): > > > > > > - SLF4J already fails on point one: it is simply a > wrapper; > > > - The Java logging API fails on point two: specialized > > classes would > > > have to be written to deal with log rotation, per-class > > filtering and > > > formatting, plus a wrapper for > Logger.{info,warning,...}() > > methods. > > > Exactly the same as a custom logger, with one more > dependency > > and using > > > more LoC; > > > > > > No dependancies, it's part of the JDK, isn't it? > > > > > > More classes need to be loaded at startup. It's just me > thinking too > > much. > > > > > > > > > However, if it's not a clearer/simpler API, it probably > doesn't make > > > much sense. > > > > > > - Log4J seems to fail on point one - it only lacks a > button > > that brings > > > back the dead. It seems interesting, and I haven't > dropped > > this yet. > > > > > > In either case (custom or external), log* would be > banished. > > Forever. > > > > > > I don't follow. You object to using a separate logs folder? > > > > > > log* == log{MINOR,DEBUG}, not the logs folder. > > > _________________________________________________ > > > Devl mailing list > > > Devl@freenetproject.org <mailto:Devl@freenetproject.org> > > <mailto:Devl@freenetproject.org <mailto:Devl@freenetproject.org>> > > > https://emu.freenetproject. > __org/cgi-bin/mailman/listinfo/__devl > > > <https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl> > > > > > > > > > > > > _______________________________________________ > > > Devl mailing list > > > Devl@freenetproject.org <mailto:Devl@freenetproject.org> > > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > -- > > GPG: 4096R/5FBBDBCE > > https://github.com/infinity0 > > https://bitbucket.org/infinity0 > > https://launchpad.net/~infinity0 > > > > > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org <mailto:Devl@freenetproject.org> > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > -- > GPG: 4096R/5FBBDBCE > https://github.com/infinity0 > https://bitbucket.org/infinity0 > https://launchpad.net/~infinity0 > > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
