On Thu, Dec 19, 2019 at 3:23 PM Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
>
>
> On Dec 18, 2019, at 11:01 PM, Remko Popma <remko.po...@gmail.com> wrote:
>
>
> I am guessing you are asking how one could go one step further and
> make the actual logger implementation completely garbage-free.
> For text-based loggers, one idea is to extract the text from the specified
> domain Object (it may not be a CharSequence, but it may implement
> some other interface that allows creating a text representation), and to
> copy this text representation into a StringBuilder owned by the Logger.
>
> The next step is to turn the text representation into bytes which can be
> written to disk or sent over a network. For this, the logging
> implementation needs to do some work with java.nio.CharBuffer, ByteBuffer
> and CharsetEncoders (and making this thread-safe can be quite involved).
>
>
> Or maybe the
> StringBuilder is provided by the logging back-end and only borrowed by
> the client?
>
>
> That is a very good point!
> (And that is one of the reasons why focusing too much on just
> CharBuilder would be a mistake in my opinion.)
>
> A SLF4J implementation could provide its own interface that applications
> could implement on objects that need to be logged without allocations.
> For example:
>
> interface StringBuilderFormattable {
> /**
> * Writes a text representation of this object into the specified
> * StringBuilder, ideally without allocating temporary objects.
> *
> * @param buffer the StringBuilder to write into
> */
> void formatTo(StringBuilder buffer);
> }
>
> The SLF4J implementation detects that the logged Object implements
> this interface, then calls the formatTo(StringBuilder) method on it with
> the StringBuilder owned by the logger. This has the advantage that the
> application no longer needs to manage any StringBuilders, and it
> reduces copying between various buffers. For example:
>
>
>
> As soon as you do this, and require that the implementation start checking if
> particular interfaces are implemented
Nothing is "required": my example illustrated one way for
implementations who want to provide extra benefits to do so, other
implementations can simply call toString on the Object.
> I have to say, why not use a Message instead.
The Message interface has four methods, which makes it a bit more
cumbersome for domain objects to implement. I suspect that only some
applications with specific needs would take the trouble to implement
Message in their domain objects.
So I would say, perhaps use a Message in addition, but not instead of Object.
> The Log4j API has been doing this for years now. It has solved the problems
> you are bringing up nicely.
The Message interface in the Log4j API is useful, but it does not solve
any of the problems I indicated. The main problem to me is that it is
still String-based. If SLF4J were to adopt a Message-like interface I
would argue that its methods should return CharSequence instead of
String.
However, in terms of being useful for allocation-sensitive application,
even such a revamped Message interface would still require domain objects
to manage their own StringBuilders, so an interface like
StringBuilderFormattable where the StringBuilder is supplied externally
would be even more useful.
> In fact I am pretty sure you implemented making some Messages reusable to
> make them garbage free.
Yes, we added a ReusableMessage interface that extends Message and
StringBuilderFormattable. That was necessary to allow the logger
implementation to extract the text without allocating.
> SLf4J wouldn’t have to do this. If it were to support a MessageFactory
> interface Log4j’s SLF4J binding could provide MessageFactories that implement
> Log4j’s Message interface so SLF4J (and Log4j) would be garbage free via the
> logging implementation, at least for some Message classes.
>
> Since you have admitted that you have to leave the existing methods alone,
> why not just go all the way?
>
> As you well know, the Log4j API still allows users to log Strings or
> arbitrary Objects. Under the covers it just puts them into a Message. The
> benefit here is that the logging implementation doesn’t have to check for all
> kinds of interfaces - it just processes the Message interface. SLF4J could do
> the same thing.
I'm not opposed to introducing a Message interface in the SLF4J API,
but it should not replace logging arbitrary objects with
Logger.info(Object).
>
> Ralph
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
