[slf4j-user] Java 5 version of SLF4J?

[Erik van Oosten]

Hi Simon,

What you describe under [1] is called escape analysis. Under most
circumstances most code and most data is unused. This can be detected,
and some compilers actually do this. As I said, I am not sure the JVM is
capable of doing this. BTW, a runtime compiler such as hotspot has many
more options to do escape analysis then a static compiler.

> That would be seriously smart optimisation though. 
I think you underestimate the cleverness of the JVM people :)

Apart from the potential performance penalty, I still think log5j has a
nicer interface. I would use it if was available for slf4j.

> I think the lack of varargs support is a feature, and good api design.
Well, I certainly do not agree there. But anyway, there are enough other
reasons for not changing the slf4j interface.

Regards,
    Erik.



Simon Kitching wrote:
> Hi Erik,
>
> You're right that the correspondence between bytecode and actual machine
> instructions is not direct. And in fact, the machine instructions
> could even vary during a program's run if the JVM is doing dynamic
> optimisation.
>
> But in this specific case,
> (a) Whether the formatting parameters are used or not depends upon the
> current setting of the logging threshold level for that category. There
> is no way the caller can determine that, so AFAICT the params will
> really have to be passed somehow. [1]
> (b) If the params are used, then they are passed as an object array to
> java.util.Formatter so an object array does need to be created at that
> point. *Possibly* a clever runtime optimiser could pass the params in
> registers, and delay creating of the object array until after the
> threshold test is done. That would be seriously smart optimisation
> though. For a start, doing this means changing the way that callers
> invoke the method, so would need to dynamically be patched into every
> callsite, not just optimise the internal implementation of a method. And
> different Logger objects can theoretically have different concrete
> implementations at runtime, so the mechanism used to invoke the call
> would need to vary depending upon the concrete implementation
> referenced. I can't see that being feasable.
>
> [1] Unless the runtime optimiser sees that the first thing the called
> method does is invoke isXXXEnabled, before using any params. When the
> calling site is using a final reference to the logger object, it would
> then be possible to migrate that call up into the calling site, and the
> effect would be like wrapping every call in isXXXEnabled, which would be
> nice. I have no idea whether any existing JVMs do this; it's fairly
> clever work. Hmm.. it would also mean presumably rewriting the called
> method so that the isXXXEnabled does not get called multiple times. But
> that would then break other callers. Ouch, this makes my head hurt  :-) 
>
> I'd be willing to bet that in everything except specialist jvms (and
> maybe there too), the log5j approach has a significant performance
> penalty due to the creation of an object array for each call, and
> therefore manually wrapping in isXXXEnabled is needed.
>
> But
>    // standard SLF4J or JCL
>    if (log.isDebugEnabled())
>       log.debug(String.format("...", arg1, arg2, arg3, arg4));
> and
>    // log5j only
>    if (log.isDebugEnabled())
>       log.debug("...", arg1, arg2, arg3, arg4);
> are identical in performance, and not much different aesthetically.
>
> The mere existence of the varargs method, however, is a performance trap
> just waiting for users to fall into, tempting them to omit the
> isDebugEnabled call. A small trap, but nevertheless there. By *not*
> providing a varargs option, the SLF4J/JCL API instead makes it obvious
> that the isDebugEnabled is necessary. I think the lack of varargs
> support is a feature, and good api design.
>
> Regards,
>
> Simon
>   

--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/