> -----Original Message----- > From: Ben Galbraith [mailto:[EMAIL PROTECTED] > > I'm using JDK 1.4.2 (or 1.4.2_01; I'll have to check). I just did a > heap dump (-Xhprof) and found that two byte[] arrays are killing my > heap, both created by JAI. I have to run now, but tomorrow I'll have > the full results of my investigation. >
Guys, Since I had a bit of spare-time, I have been using this to do a little profiling. I must admit though, I had never used one of these before (-but since you're convinced this isn't that hard, I thought I might as well have a go :) Sure could do with the exercise. DL'ed some tool called JProfiler... Pretty neat, apart from the fluffy-XP-WinToys-look -- Aqua forever!! :) ) So, although most of what I'm seeing & reading makes perfect sense to me, I'm a little stuck in interpreting these results. So, with the risk of uttering a few silly remarks, a few observations (as revealed by a heap snapshot taken _after_ : - the rendering of a single document - the 'extensive.fo' example that comes with FOP, since svg was mentioned and this example contains an embedded svg - I've also done tests with the embedded svg example, as well as with slight modifications of the ExampleFO2PDF program performing the same rendering (embedded.svg) 15 times and 150 times - I put the loop in the main-function ) - the charts: 1 Run Before GC - 37671 objects in 1096 classes - 26442 arrays 15 Runs Before GC - 44340 objects in 1109 classes - 29029 arrays 150 Runs Before GC - 43149 in 1109 classes - 28155 arrays 1 Run After GC - 29962 objects in 993 classes - 21542 arrays (results after gc are similar with 15 runs or 150 runs, in absolute terms) In all cases (1 run / 15 runs / 150 runs ): TOP 5 in instances are char[], java.lang.String, int[], java.util.HashMap$Entry and org.apache.xerces.qni.QName ( the first two logically tied together because String is actually an object itself with a value-field of type char[], the fifth because it has two fields - rawname and localpart - that are of type String ) TOP 5 in size are char[], byte[] and <class>[], java.lang.String and short[] The remnants of byte[] on the heap indicating incoming references from mainly java.util.zip, java.util.jar and the <class>-arrays. The <class>-arrays, I believe, *might* be indications for such a hanging List/Map/HashMap/Hashtable ( correct? ) Following the number of object instances created during execution ( 15 or 150 runs, you can see the Garbage Collector at work... char[] grows, but never exceeds 2.6 MB ( total heap never exceeds 5.5 to 6 MB during 150 runs ) Snapshot taken after performing a garbage collect indicates about 600K of memory being released (2 MB after 15 runs - seems to indicate that there is indeed an accumulation of some sort taking place, but it remains 2 MB for 150 runs - I guess this has to do more with the automatic GC being performed only when it becomes necessary), so it does have some result. After gc, char[] still takes up about +600K ( same amount in all three testcases ) In short, it seems to me that there's nothing really anomalous. ( The <class>-arrays, being referenced by java.util.zip and java.util.jar - which actually comes down to the same, as jar subclasses zip - seem like they have to do with the way the VM treats the jars on the classpath... Checking the instance data reveals lots of these to be referenced by java.util.jar.Manifest ). Then again, I may have overlooked something... Feel free to correct me :) Enjoy! Andreas Delmelle --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
