Date: Thu, 28 Jul 2005 14:07:05 -0600 From: Nate Williams <nate@yogotech.com> To: Christopher Farley <chris@northernbrewer.com> Cc: freebsd-java@freebsd.org Subject: Re: JVM crashes Message-ID: <17129.15081.670574.582298@emerger.yogotech.com> In-Reply-To: <20050728141622.GA17226@northernbrewer.com> References: <20050728141622.GA17226@northernbrewer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm running jdk-1.4.2p6_3. > > One of my programs is causing the JVM to crash with the following error: > > Exception in thread "CompilerThread1" java.lang.OutOfMemoryError: > requested 32760 bytes for ChunkPool::allocate. Out of swap space? Try increasing your heap size using -Xms -Xmx. It's possible that the defaults are not large enough for your application. > A search of google brings up loads of problems related to Tomcat, but > this program has nothing to do with Tomcat. To my knowledge, none of the > libraries I am using use JNI code at all. If your application uses/needs alot of memory, then the default may not be large enough, so while most people experience the problem using Tomcat (simply because they have *lots* of small applications), you may be experiencing the same problem due to using one 'large' application. (Where small and large are descriptions of memory use). > First, is there anything programming error that could cause this crash? There could be. If you are using UI components (Swing, etc..), then they must be properly disposed of. Also, certain OS specific objects may also need to be properly closed (files, sockets, etc..) In addition, certain algorithms are better than others for memory use. Most algorithms make a tradeoff for speed (CPU) vs. memory, and depending on your environment, you may need to choose an algorithm that runs a bit slower but uses less memory. However, aside from objects listed above, Java is pretty good about clearing up unused memory, and even pretty good about compacting memory when necessary. > I need to know if I should be scrutinizing my code for memory leaks, > etc. I have run the program through a memory profiler, but not the > production system... Everything looks okay. Sounds like you've done your homework. In this case, I'm guessing that the defaults simply aren't large enough for your production application, which simply needs more memory than is provided by default. The only other cause would be an OS issue where your process memory limits are being hit, causing Java to be killed when it attempts to allocate more memory than the OS is allowing. For the latter, check your login limits. I believe the handbook has entries on these. Check for entries that discuss login.conf and friends. > Finally, if one of my libraries is causing this to happen, how would I > go about determining the cause? The memory profiler should be able to detect where in your application this occurs. > One final, probably irrelevant detail -- the jvm will usually crash > within the first couple of hours of being launched. If it survives more > than a few hours, it seems to go on forever with no problems. I haven't > seen any other pattern in the crashes! Again, this could happen because once your application gets to a certain point, the workload (and memory usage) doesn't change significantly, so there is no additional memory being requested, hence the program doesn't die when it asks for more memory. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17129.15081.670574.582298>