logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Problem with String.intern() in CategoryKey
Date Wed, 11 May 2005 16:29:41 GMT


Thanks for this interesting report. I wonder how representative your 
example is. For example, you seem to internalize thousands if not millions 
of strings. Does this match your deployment scenario? In other words, how 
many loggers do you create?

At 11:11 5/11/2005, Vincent Shek wrote:
>Hi all,
>I hesitate to send this email to this list as opposed to Bugzilla but I
>would to get some opinion here first before I do so.  I am facing a strange
>performance problem in our production environment when I use the conversion
>pattern "C:L" to output class name and line number.  I DO expect the
>performance to be slower but what I got was a gradual slowdown where our
>application would literally slow down to a grinding halt after a few days of
>running.  The application would get back to normal if I force it to run a
>full GC.  After working with HP JVM engineer on this issue, the problem was
>found to be the use of String.intern() in CategoryKey class AND the use of
>java.lang.Throwable.getStackTraceElement() (to get line number and
>classname).  The use of intern() causes the StringTable in JVM (in the
>Permanent heap) to fill up very quickly as each call to Logger.getLogger()
>will create an instance of CategoryKey object.  The method
>getStackTraceElement()  will use the StringTable for lookup and it will take
>longer for it to run as time goes. The StringTable may contain Strings which
>are not live in the java program.  However, the collection of Strings in
>StringTable is done only in Full GC.  That's the reason a Full GC recovered
>the application performance. I have attached a sample program that will
>reproduce the problem easily on any platforms using 1.4.2 JVM.
>My question to the logging group is whether the call to intern() is
>necessary in creating the CategoryKey? Is it used to speed up hash lookup?
>This seems like a VM bug but I doubt it will get fixed by Sun anytime soon
>and I am worried that other system will experience the same problem I do.
>(took us a few weeks to figure out the problem!)
>TIA for your help,
>Vincent Shek
>This email is confidential. If you are not the intended recipient, please
>notify the sender immediately.  The unauthorized use, disclosure,
>dissemination or copying of this email is prohibited.  Emails are
>susceptible to alteration and their integrity cannot be guaranteed. Tai Fook
>Securities Group " Tai Fook" does not accept liability for damage caused by
>this email.

Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/

View raw message