Re: Tracking down unwanted object retentions that are eating memory

    Hi James,

> we were intern()ing a large number of very long (like in
> 40kb each) strings BEFORE trimming them to their "active"
> length.

    Yep, that would do it.  While it's not a memory leak in the classic
sense, because the whole point of intern() is to keep Strings in a memory
pool, the effect is the same when the interned String isn't actually needed.
Sounds like one of those premature optimization things.

    I'm glad you were able to find the problem though, I know that kind of
thing is maddening.  And clients don't always get the "it took five minutes
to fix, but two weeks to find the problem."


                                                         Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400


----- Original Message ----- 
From: "James H H Lampert" <jamesl@xxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Thursday, May 18, 2006 6:27 PM
Subject: Re: Tracking down unwanted object retentions that are eating memory


> Actually, suggestions of profiling/debugging/whatever
> utilities was what I was angling for, but the whole
> situation just became moot.
>
> It seems that I stumbled over the memory leak quite by
> accident, while looking up something else. It seems that
> we were intern()ing a large number of very long (like in
> 40kb each) strings BEFORE trimming them to their "active"
> length. And I discovered what a huge waste of both time
> and space it is, to intern() a string, then throw out the
> version you'd intern()ed.
>
> Oops!
>
> --
> JHHL
> --