xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: java.lang.OutOfMemoryError
Date Mon, 06 Dec 2004 15:39:20 GMT
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:Thomas.DeWeese@Kodak.com] 
> 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
> (#instances@t2 - #instances@t1) or is that just the number of new
> instances (#instances@t2 - #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: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message