Hi Charlie,
Ok this tells me a little more, so for example the char [] may have started with 6K instances, of which we have dropped almost all, but we added 17K new instances (meaning a total gain of ~11K instances).
Do you have a good explanation for the growth in ObjectStream stuff? It looks to me like these aren't getting cleaned up properly and depending on what they are they could be keeping Batik stuff live.
Also any idea what "<class>[]" is? If it's actually anything to do with real class files it is disturbing to see it grow by 14K entries.
Tang, Charlie Y. wrote:
Sorry I wasn't really clear, the bar graph in the html file have two colors, one is green, the other is burgundy, the green indicates the instance count at time 1, (which I set after the program ran for 10-20 mins) and burgundy represents the instance counts that have increased over time, the int[] 's instance have increased dramatically, however the size of it was around 8,100,000 to start. As the program was running, the instance count of all class would change periodically, increase and then decrease, because of Garbage collection, so usually they would revert back to minimum increase,(the number in the difference category would be small). However over time, the highest instance count of the first 5 class started to go higher and higher, from around 5k - 6k to the latest count of over 10k and up to 17k or so.
I understand this doesn't tell a lot about what the cause of this increase over time is. thx
-----Original Message-----
From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: Monday, December 06, 2004 9:51 AM
To: Batik Users
Subject: Re: java.lang.OutOfMemoryError
Tang, Charlie Y. wrote:
I've included an html output of JProfiler with which the program was
ran
for 4 days or so.. it appears the problem lies with some of the java
primitives that batik maybe using such as char[] ?!
Hi Charlie,
Thanks for including this, however I'm a little unsure of how to read this. So the major hitters are "char[]", "byte[]", and "int[]" (int[] being the largest by far). My suspicion is that the new "char[]" are almost all string instances, and the byte[] and int[] arrays are almost all BufferedImage data.
However, what I'm unsure of is what the Difference column is telling us. So if we created 17K new strings that is only a problem if we don't drop 17K old strings. So do you know is that an "aggregate" string instance change ([EMAIL PROTECTED] - [EMAIL PROTECTED]) or is that just the number of new instances ([EMAIL PROTECTED] - #instances still live from t1)?
Also this tells me a little about what the problem might be, but really what needs to be done is to look at a sample of the new live instances and see what is keeping them live (and what is keeping them live, and what is keeping them live... until you get to something "interesting").
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
