[Bug awt/29420] OutOfMemory in image handling

[fkung at redhat dot com]

------- Comment #20 from fkung at redhat dot com  2006-11-07 18:52 -------
Hi Norman,

Interesting... I'm at a 600 pictures, 1600x1200, and jamvm isn't even sweating.
 Memory use stays within a 5 mb range, and the total heap hasn't gone over 50mb
(for a 500mb maximum).

On cacao, however, with the same pictures and settings, the heap quickly grows
to the maximum and it Out of Memory's after 10-15 pictures. 

---
And I've just read your last comment, so I'll reply to that as well.

(In reply to comment #19)
> I just built cacao-0.97 (because 0.96 doesn't work with current cvs somehow),
> and ran some new tests. Summary:
> 
> 2. cacao seems not to garbage-collect image memory; leaks about 20M+ per 
>    image and seems to ignore the -Xmx parameter completely. Running a 
>    slideshow crashes when system memory is exhausted.

cacao doesn't seem to garbage-collect as frequently; it could well be that
cacao's garbage collection can't keep up or is buggy (or that we rely on
non-standard garbage collection behaviour somewhere in classpath...).  I can
reproduce the OutOfMemory very quickly with cacao.

> 4. To test for image-format dependencies, I created two new subdirectories
>    with 1000 identical copies of a reference image (800x533), once in JPG
>    and once in GIF format.
> 
>    Running a slideshow in jamvm in either of these directories results in
>    a flat memory usage of ~67M RES (as reported by top). No crash. (!)

I was starting to suspect something like this; that's probably why I can't
reproduce the crash with jamvm: my test images have been all the same size

> 5. Same with 1000 GIF images of 1200x800: jamvm allocates ~148M RES, but
>    seems to stay flat from there.
> 
> 6. Running a slideshow in a directory with 3000 images of just four 
>    different sizes (1200x800, 1300x700, 900x1100, 500x900) but in random
>    order allocates up to 300M (at -Xmx200m) and then crashes.

So it's got something to do with changing image sizes... I'll change my test
data to match.

> So: is there any reason that the Heap might get fragmented, and the
> garbage-collector cannot "repair" this?

I have no idea... I really don't know much about garbage collector or JVM
internals =(

> Is there any reason that both jamvm and cacao ignore the -Xmx parameter?

The -Xmx setting only applies to the java heap.  Any memory that we allocate in
native JNI methods (and there are quite a few of them, especially in image
work) won't count towards the Xmx setting...  and thus, a memory leak in native
code wouldn't cause an OutOfMemoryError (it would go through all system and
swap memory first, before crashing in some horrible way)

Thanks for being so persistent with this!
Francis


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29420