Hi David, David Avery <[EMAIL PROTECTED]> wrote on 10/27/2005 01:55:20 PM:
> Unless it's flushed the cache contents seem to persist in the heap > untill the JVM expires. If so it's a major bug in the JVM. The URLImageCache class uses java.lang.ref.SoftReference to reference the image data and it has a ReferenceQueue registered to remove the key's who's data have been GC'ed. There is some small chance that there is a bug in this code, but it's been around a while and I've stressed it quite a bit in the past. It is an explicit part of the JavaDocs on SoftReferences that all of then GC'able references must be cleared before an out of memory exception is thrown. As for the purpose, it's mostly to avoid reloading image data when it is referenced multiple times by the same document. If you can produce a stand alone test case where not calling flush reliably causes an out of memory error, but calling flush prevents it I would be very interested in seeing it. > Archie Cobbs wrote: > > > David Avery wrote: > > > >> Well I figured it out. > >> canvas.flushImageCache(); > >> > >>> After about 8 reloads batik seems to be using a hugh amount of memory, > >>> provoking a java.lang.OutOfMemory. > >> > > > > Interesting... so what's the image cache and what does it do? > > > > -Archie > > > > __________________________________________________________________________ > > > > Archie Cobbs * CTO, Awarix * > > http://www.awarix.com > > > > --------------------------------------------------------------------- > > 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]
