geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [Logs] Re: Logging code and Garbage Collection
Date Fri, 15 Aug 2003 12:54:01 GMT
Dain Sundstrom wrote:

> Man did you have me pissed off when I read this.  You almost got a 
> flaming response, but I trashed it and you are getting this one...
> Alex,
> I boil the issue down as follows, excessive calls to isXEnable is bad 
> because of the excessive overhead.
> Agreed?

IMO, its too early to tell on this point.  Those calls will be made
regardless of whether we do it explicitly or not.  Anyhoo, it really
isn't worth wasting breath arguing about the issue.  At this point,
if you are absolutely convinced that the isXEnabled check must be
cached, then we might as well do it the best way.

> 1) cache the value and invalidate based on a notification from the 
> logging framework
> 2) cache the value and invalidate on an interval bases
> Agreed?

:/  Hmm.  What about using lastModified() semantics.  If the value has not
been modified in X number of minutes, then we can recheck the old implementation
of the isXEnabled.  The solution does not eat up a thread to do the check.

> BTW here is my justification.  isDebugEnabled looks like this:
> public boolean isDebugEnabled() {
>     if (repository.isDisabled(Level.DEBUG_INT)) {
>         return false;
>     }
>     return Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel());
> }

That's only one implementation.  It might be better to fix Log4J.  BTW,
how does JDK 1.4 Logging work?

<snip type="code">

> According to the extensive testing Jeremy and I did on the fastest way 
> to implement the locking system, the most expensive thing in raw java is 
> volatile variables.  It was actually faster to synchronize and get the 
> value, but that may reduce concurrency.  This was not a problem for 
> locking as it is designed to control concurrency.  My code on the other 
> hand, caches the value of this expensive call and keeps it in an 
> non-synchronized non-volatile variable.  At noted in the code this is OK 
> because boolean assignment is atomic and at the worst case we will have 
> running threads with an outdated processor cache of the value, which is 
> OK as this is designed to be an out of date cache.  So unless you turn 
> off debug for the entire hierarchy there is no way my code can be slower 
> and if you have turned it off for the entire hierarchy, my code should 
> be no slower.

Category is for an old version of Log4J, does this problem still exist in
the new code?

Anyway, I'm not trying to ruffle feathers, but just point out that the
same thing can be done without eating up precious resources like Threads.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message