As an addition to this, I should point out that you do see the memory reclaimed eventually. About three to four hours in idle time on my test system, sees the RSS drop to around the levels seen with the trimToSize() addition - probably the time it takes for the GC to find the areas to reclaim.
However, this probably detracts from the performance. If I'm reading it correctly, 20Mb of memory is a lot to clean up, and in my books, a lot to give up. Since it happens at the metadata-read stage of proceedings, I guess redeployments are also going to be affected. If you have a big deployment, you might appreciate the immediate memory reclaim and the reduced GC interruption later. JonB > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jon Barnett > Sent: Tuesday, 1 July 2003 11:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] On the performance trail - again > > > As an aside (and up front before the other numbers), I cleaned up some > code around the MetaData area so that ArrayLists were trimmed and the > other methods getUniqueChild, etc called my new getChildArrayByTagName > method. I also finalized methods in this area and Containers and took out > variable declarations within loops in these areas. The results were: RT: > 115 ms (no change), min. 30 ms, max 3405 ms, VSZ: 183516Kb (down 0.37%), > RSS: 106756Kb (down 17.57%). I probably gave up any performance gains for > cleaning memory on the spot. It was interesting the in-memory use dropped > that much. But IBM take the opposite view - sacrifice memory for speed.
smime.p7s
Description: S/MIME cryptographic signature
