From owner-freebsd-java@FreeBSD.ORG Thu Jul 28 20:07:10 2005 Return-Path: X-Original-To: freebsd-java@freebsd.org Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2C4B16A41F for ; Thu, 28 Jul 2005 20:07:09 +0000 (GMT) (envelope-from nate@yogotech.com) Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 461B943D46 for ; Thu, 28 Jul 2005 20:07:07 +0000 (GMT) (envelope-from nate@yogotech.com) Received: from emerger.yogotech.com (emerger.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.13.3/8.13.3) with ESMTP id j6SK76vs033957; Thu, 28 Jul 2005 14:07:06 -0600 (MDT) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by emerger.yogotech.com (8.13.3/8.13.3) id j6SK75QC077340; Thu, 28 Jul 2005 14:07:05 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17129.15081.670574.582298@emerger.yogotech.com> Date: Thu, 28 Jul 2005 14:07:05 -0600 To: Christopher Farley In-Reply-To: <20050728141622.GA17226@northernbrewer.com> References: <20050728141622.GA17226@northernbrewer.com> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Cc: freebsd-java@freebsd.org Subject: Re: JVM crashes X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Williams List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 20:07:10 -0000 > 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