bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug awt/29420] OutOfMemory in image handling


From: hendrich at informatik dot uni-hamburg dot de
Subject: [Bug awt/29420] OutOfMemory in image handling
Date: 7 Nov 2006 18:23:02 -0000


------- Comment #19 from hendrich at informatik dot uni-hamburg dot de  
2006-11-07 18:23 -------
I just built cacao-0.97 (because 0.96 doesn't work with current cvs somehow),
and ran some new tests. Summary:

1. cacao deadlocks instantly when specifying a directory name on the command
   line, probably a cacao bug: cacao -Xmx200m niffler.Niffler <directoryname>
   hangs. 

   When no directory argument is given, the GUI starts up fine. Afterwards,
   a directory can be selected (minus the crazy scrolling issues in 
   JFileChooser). The first images are loaded fine, but then:

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.

3. My previous tests were done on my "main" image collection, residing on
   a Windows FAT32 partition (vfat). I copied the images to a native ext3
   partition. Image loading seems slightly faster under jamvm, but a 
   slideshow still crashes (about the same number of images as FAT32).

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. (!)

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: is there any reason that the Heap might get fragmented, and the
garbage-collector cannot "repair" this?

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


-- 


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]