From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22995 invoked by alias); 1 Apr 2011 17:41:16 -0000 Received: (qmail 22982 invoked by uid 22791); 1 Apr 2011 17:41:14 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_GC,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; Fri, 01 Apr 2011 17:41:10 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Fri, 01 Apr 2011 10:42:07 -0700 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 10:41:10 -0700 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 10:41:10 -0700 Message-ID: <4D960E35.90807@caviumnetworks.com> Date: Fri, 01 Apr 2011 17:41: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: Erik Groeneveld CC: java Subject: Re: GC leaks debugging References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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-04/txt/msg00009.txt.bz2 On 04/01/2011 01:39 AM, Erik Groeneveld wrote: > L.S., > > I am debugging memory leaks in the GC of libgcj. Generally, libgcj > performs well, but there are some cases in which the heap literally > explodes over time. I wish to solve this. The OpenJDK vm runs the same > tests without any leaking. > > I compiled GCC 4.6, build with --enable-libgcj-debug=yes and started > testing with GC_DUMP_REGULARLY=1. From the results I have a few > questions to understand it better. I am still in a phase of > pinpointing a minimal program to demonstrate the problem, and I would > like to get hints as to search further. > > 1. The finalization table entries keeps on increasing up to 39344 > until it is killed, but the objects which are eligible for immediate > finalization remains 0. It seems that no finalization takes place. > Could you give any hints as to what could be the reason for this? It > logs: > You should also look at: http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcj/Invoking-gc_002danalyze.html#Invoking-gc_002danalyze David Daney [...]