From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3465 invoked by alias); 17 Jan 2011 17:32:40 -0000 Received: (qmail 3456 invoked by uid 22791); 17 Jan 2011 17:32:40 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_GC,TW_IB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Jan 2011 17:32:35 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Mon, 17 Jan 2011 09:33:23 -0800 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 09:32:34 -0800 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 09:32:34 -0800 Message-ID: <4D347D2D.4010101@caviumnetworks.com> Date: Mon, 17 Jan 2011 17:32:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Ben Keppler CC: java@gcc.gnu.org Subject: Re: FW: Garbage collection issues in GCJ References: <3C7F46E08E936B478463BFFA776CDAD30168E7F7@tmsmail.domain2.local> In-Reply-To: <3C7F46E08E936B478463BFFA776CDAD30168E7F7@tmsmail.domain2.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00008.txt.bz2 On 01/17/2011 05:08 AM, Ben Keppler wrote: > We are using gcj for a time sensitive application. One of the > requirements of the application is that messages be transmitted > within a 60ms timeframe. Unfortunately, the Boehm GC used in gcj is > not generational and thus every collection is of the "stop the > world" variety. We are observing (using "GC_PRINT_STATS") regular > collections that stop the world for periods in the 400ms range. > This is a problem for us. > > The comments I have found on the "incremental" setting for the > Boehm GC indicate that it doesn't work with gcj, so that would not > appear to be an option. My question is, are there other GC options > (perhaps a generational garbage collector) available for gcj? My > research has revealed none other than TinyGC, an option that would > exacerbate rather than relieve our problems. Alternatively, are > there settings on the Boehm GC that might relieve our problems? I > would appreciate any information you could provide. 1) GCJ's libjava is not really suited for realtime applications. 2) Setting the GCFreeSpaceDivisor (by calling _Jv_SetGCFreeSpaceDivisor()) to a low value (try 5) may result in shorter, but more frequent, GC intervals. Limiting the total heap size will also reduce the amount of work done by the GC during each collection. David Daney