geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject Re: Logging code and Garbage Collection
Date Wed, 13 Aug 2003 16:02:44 GMT

On Wednesday, August 13, 2003, at 04:26  pm, Jeremy Boynes wrote:

>> From: Jason Dillon [mailto:jason@coredevelopers.net]
>>
>> I would depend on how it was cached.  If you mean if a method
>> traces or
>> debugs more than once, it should definitely create a local
>> variable to
>> cache if the level is enabled, but if you mean for a larger scoped
>> cache, this could make it hard to debug a running server, as you can
>> always tweak the active levels at runtime.
>>
> Local variable, a given.
>
> The thing is, the isXEnabled() method gets called a gazillion times to
> detect the one time that the level was bumped up, which happends very
> infrequently. I'm assuming this goes through a synchronized block as
> well, add yet more ns to the call. The runtime feature is useful but 
> has
> a price.
>
> Some form of lazy caching scheme may be appropriate, provided checking
> invalidation is quicker than the call to isXEnabled().

Since the isXEnabled() methods are so simple, we could have a volatile, 
boolean flag cached representing the state of whether or not logging is 
enabled so that there's no synchronizing and the implementation is very 
fast (and inlined) by the JVM.

Using log4j code names here - each Logger could register (with a weak 
reference) with the LoggerRepository  so that when the logging changes, 
the Logger's could be notified ('pushed') to update their cached flags. 
Sure it'd use a bit more RAM (could use 1 byte per logger if need be or 
4 boolean flags for simplicity) though it should be much faster. Right 
now each isXEnabled() calls a method on a shared object which is 
synchronized (LoggerRepository.isDisabled()).

I wonder if the log4j folks thought of this?

We should remember though - premature optimisation is the root of all 
evil - do we have the test metrics to prove this is the problem? I 
guess hacking together a quick test case should be quite easy of 2 
equivalent commons-logging implementation - one using log4j and one 
using a cached boolean.

James
-------
http://radio.weblogs.com/0112098/


Mime
View raw message