Following an OutOfMemoryError I processed the resultant heapdumps through IBM Support Assistant's 64bit memory analyzer ( J9 VM running on Websphere 7.0.23)
Several leak candidates were listed ( all system classloader related ) however one of these appears to indicate that a char[] initialised with a value of 256 in StringBuffer actually contains 77 million null characters.
The resultant heapdump analysis from the Support Assistant shows a char[77418987] @ 0xc32*** \u0000\u0000\u0000.......
this is referenced by StringBuffer -> PatternLayout -> TimeAndSizeRollingAppender
The retained heap checks out, 2 bytes for each char and 18 for the array itself for a total of 150+ Mbs.
Log4j version is 1.2.16 and we use the simonsite TimeAndSizeRollingAppender ( though I would like to remove this dependency ).
Could this be a false positive from Support Assistant or is there some way in which a char[256] can become a char[77000000+] on the heap?
By default, WebSphere generates a PHD file in response to an OOM event. One thing you need to be aware of is that these dumps contain information about the objects in the heap and their references, but not the actual data stored in attributes and arrays (of primitive types). That's why the memory analyzer only shows zeros. To get more information about the root cause, you should configure your WebSphere to create a system dump. That will allow you to see the data in the array and should give you a hint about what is happening.
The following link explains how to do this:
For the 256 vs. 77000000+ question: 256 is only the initial capacity of the StringBuffer. It grows automatically as needed when data is appended.