The previous program about which I've previously posted is periodically having memory issues. Through judicious placement of printlns, I've narrowed it down to a particular point. The last programmer created a loop in which new ImageIcons are created, and that's where I'm getting the error. To whit, here's the relevant section:
and here's the output:
... and thereafter whenever it creates new ImageIcons it gets OutOfMemoryErrors, and slows down considerably.
I'm sure I could be more learned about this subject. Are there any glaring errors in the above method of populating a Vector with ImageIcons? Should I be doing on-the-fly object recycling? Are there any good places to read about how these sort of things work (or don't work, in this case)? [ May 16, 2007: Message edited by: Zachary Anderson ]
Joined: Oct 14, 2005
I'm assuming the reason noone has responded to this one in over a week is that it had a "humorous" title; sorry about that. I'm retitling it and bumping it with the hope that someone in JavaRanch knows what to do with java.lang.OutOfMemoryErrors.
Aside from the discrepancy in code which Ricky pointed out, it looks like you're adding each image to a Collection called Images. Does anything ever remove things from this collection? How many images are you putting in there? Isn't it possible you're getting OutOfMemoryError for the simple reason that you're using too much memory? Perhaps if you have a large number of "trials" you should clear the collection - or just replace it with a new, empty one - at the beginning of each new trial? [ May 17, 2007: Message edited by: Jim Yingst ]
JAVA Out of memory error comes in two cases either the file size is too large for JVM or database is not able to support such a large file.
You can avoid it by using XMS and XMX parameters of Java
For helping you any further i will like to know : what IDE are you using what application server you are using and what is configuration of server machine that is RAM and OS
Joined: Oct 14, 2005
Mr. Clarkson, The description is correct. The previous programmer wrote the "catch exception e", I'm not sure what his rationale was; I specifically added print"Exceptional e" to differentiate errors showing up in my program from those in java classes. My guess is that the java.lang.OutOfMemoryError is happening within either the ImageIcon or File class.
Mr. Yingst, (One of the hazards of being a repair programmer rather than an original programmer) I'm not sure whether anything is removed from Images or not; I will look through the imagehandler for such. There are 9 images per trial, and the standard battery of trials is 10, so I'd like to be able to do 90 images; it's currently getting bogged down around 50 (a little more than first reported, I'm guessing because I have more free memory at the moment). Replacing the image vector every time is possible, but part of the appeal of having a fully pre-loaded image collection is I can make sure the images aren't repeated during a battery; I can make a process that only uses each image name once. It'd be much messier to make a process that does such with ... well, there's an idea, actually. I'll try a smaller vector and we'll see how it goes. Or maybe use a String with the filenames, and only create the ImagesIcons when needed. Would this slow down run time?
Mr. Anand, I'm not sure what XMS or XMX parameters are, will have to look those up. Using JBuilder Foundation 2005 (the outofmemoryerrors come up in red!), Java(TM) 2 Platform Standard Edition binary, 512 MB of RAM, and Windows XP 2002 (Service Pack 2).
I'm not sure what someone meant by "JAVA Out of memory error comes in two cases either the file size is too large for JVM or database is not able to support such a large file."
you can run out of memory if you just create too many objects and save the references.
XMX and XMS are parameters to the JVM setting how much memory to give iteself, but i'm not sure of the details. Simply giving yourself more won't fix the problem, if you keep creating too many objects - you can still run out of memory eventually.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
-Xms and -Xmx are flags to set the starting heap size and maximum heap size. I believe the defaults are -Xms32m -Xmx128m (32MB to start, with a maximum of 128MB). So, for example, you might use the command...
java -Xms64m -Xmx512m MyClassName
(I'm running a program with these values as I type this. We'll see what happens...)
But: This is no way to handle leaky or sloppy code.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Originally posted by marc weber: ... I believe the defaults are -Xms32m -Xmx128m (32MB to start, with a maximum of 128MB).
The defaults are different for different versions of the JVM; Sun's 32-bit client JVM for Windows has a default max. of 64 MB (not 128 MB). Other variants of Sun's JVM (the server version, the 64-bit version, or for other operating systems) have different defaults. [ May 21, 2007: Message edited by: Jesper Young ]
Given Mr. Weber's previous admonition, I ended up changing the code such that it made a String of image names, and only made ImageIcons as they come up. I can now go through dozens of trials with no ".outofmemory". I haven't tested it to breaking, and I'm guessing that it simply won't; the most ImageIcons it's using at any one time are nine, and after it finishes painting them there aren't any future references to them, so they should be garbage collected shortly after being put on the screen.
Small downside, I have noticed a slowdown in the runtime when painting more than four Icons, but it's still operating within acceptable parameters so I'll let it occasionally be slow.