Hi Ernst, Like most things Java, there are two viewpoints. I often hear that OOME is the last gasp of the JVM and that all attempts at recovery are futile -- sort of like being Boorg'ed.
I don't believe that. It's an urban myth... In fact, I have a small applet that exhausts all memory and lives to tell the tale. http://pancyl.com/memoryhelp.htm What I think is that the guys who developed the memory allocation scheme for Java were smart enough to check to see if there was enough memory for the next allocation *BEFORE* they allocated it. My reasoning is that even though the next memory allocation may indeed require more than all available memory, before that last chunk is allocated, there is still enough to recover by dumping some objects (o = null;) and/or System.gc(). That's what my little applet does. It waits for the OOME to be thrown and then dumps what it has allocated and runs System.gc(). The problem I described is that ImageFetcher just suspends and doesn't signal the OOME so that I can take steps to recover. Ken Ernst de Haan wrote:
Ken, Question is whether OOMEs can be handled gracefully at all. I'm not an expert in this field, but it may be that the JVM enters an error state as soon as this error is triggerred. Note that the JVM self may be unable to get sufficient resources for its basic operations. But then again, I'm not an expert. But I have witnessed heated discussions on this topic, a few years ago. So my suggestion is to first do some research to confirm OOMEs can in theory be handled gracefully. Cheers, Ernst
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
