You're right, the example you gave will put the arguments on the
stack. I wanted to clarify Escape Analysis in its current form works
only if a new object doesn't exit the stack frame where it's created.
Because of that, the moment you do something slightly more complicated
you will create garbage like this:
private static void logListSize ( final List<?> listToLog ) {
LOG.log(" list size is {1} ",
new Object() {
public String toString() {
return String.valueOf(listToLog.size());
}
});
}
Here is the tricky part - if you can guarantee that everywhere in the
jvm the LOG.log method is disabled by the logging system, then the
entire call will compile to noop and no objects will be created.
However, if even one call site enables logging you will end up
creating the temp objects even if they don't get logged. Below is a
full example, compile and run passing "-verbosegc -XX:+PrintGC" and
watch it GC all the time.
===== LazyEvalTest.java ===
import java.util.*;
public class LazyEvalTest {
// only if this is is always false does logging produce no garbage.
private static boolean shouldLog = true;
private static void log(String ar1, Object ar2) {
if (shouldLog)
System.out.println(ar1 + ar2.toString());
shouldLog = false;
}
public static void main(String []ar) {
final List<Object> listToLog = new ArrayList<Object>(1000);;
while (true) {
log(" list size is {1} ",
new Object() {
public String toString() {
return String.valueOf(listToLog.size());
}
});
}
}
}
======
As far as garbage collection times go, they are a function of the
count of live objects and on how easy it is to scan them in parallel
and a whole bunch of other factors. Others can answer better what
values are common for Fred.
Zlatin
On Thu, Mar 22, 2012 at 11:47 PM, Ximin Luo <infini...@gmx.com> 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 <infini...@gmx.com
>> <mailto: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>
>> > <mailto: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>>
>> > > <mailto: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>>
>> > <mailto: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>
>> <mailto: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
>> <https://launchpad.net/%7Einfinity0>
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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 <https://launchpad.net/%7Einfinity0>
>>
>>
>> _______________________________________________
>> 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
