Yes, kids, both your penisses are incredibly long. Now shut up and let the
grown-ups do some refactoring.
Greetings,
David
On 23.03.2012, at 04:47, Ximin Luo wrote:
> LOL, are you kidding me?
>
> Please point to the exact lines of code that results in "double-digit
> millisecond pauses"?
>
> Talk is cheap, show us some numbers.
>
> BTW, the "example" I gave is not real code, and contains no variable
> declarations, so your challenge makes no sense. Since you apparently didn't
> understand my implicit argument, here it is in more detail: a typical method
> that computes something simply for the purpose of logging it somewhere,
> usually
> only allocates local variables that are not stored anywhere in the long term.
> Escape analysis can turn these into stack allocations, saving GC overhead. (If
> they do use more long-term variables, they will need to be stored on the heap,
> but then GC doesn't need to clean these up anyway.)
>
> Why are you even looking at blog entries? Escape analysis has been around for
> years. http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/357d4e2eb4dd
>
> On 23/03/12 02:06, Zlatin Balevsky wrote:
>> 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 <infinity0 at gmx.com
>> <mailto:infinity0 at 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" <infinity0 at gmx.com
>> <mailto:infinity0 at gmx.com>
>>> <mailto:infinity0 at gmx.com <mailto:infinity0 at 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.schulze at gmail.com
>> <mailto:marco.c.schulze at gmail.com>
>>> <mailto:marco.c.schulze at gmail.com <mailto:marco.c.schulze at
>>> gmail.com>>
>>>> <mailto:marco.c.schulze at gmail.com
>> <mailto:marco.c.schulze at gmail.com> <mailto:marco.c.schulze at gmail.com
>> <mailto:marco.c.schulze at 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 at freenetproject.org <mailto:Devl at freenetproject.org>
>> <mailto:Devl at freenetproject.org <mailto:Devl at freenetproject.org>>
>>> <mailto:Devl at freenetproject.org <mailto:Devl at freenetproject.org>
>> <mailto:Devl at freenetproject.org <mailto:Devl at freenetproject.org>>>
>>>> https://emu.freenetproject.__org/cgi-bin/mailman/listinfo/__devl
>>>> <https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Devl mailing list
>>>> Devl at freenetproject.org <mailto:Devl at freenetproject.org>
>> <mailto:Devl at freenetproject.org <mailto:Devl at 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 <https://launchpad.net/%7Einfinity0>
>>>
>>>
>>> _______________________________________________
>>> Devl mailing list
>>> Devl at freenetproject.org <mailto:Devl at freenetproject.org>
>> <mailto:Devl at freenetproject.org <mailto:Devl at freenetproject.org>>
>>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>>>
>>>
>>>
>>> _______________________________________________
>>> Devl mailing list
>>> Devl at freenetproject.org <mailto:Devl at 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 <https://launchpad.net/%7Einfinity0>
>>
>>
>> _______________________________________________
>> Devl mailing list
>> Devl at freenetproject.org <mailto:Devl at freenetproject.org>
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>>
>>
>>
>>
>> _______________________________________________
>> Devl mailing list
>> Devl at 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 at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
