From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1987 invoked by alias); 8 Apr 2011 15:48:44 -0000 Received: (qmail 1964 invoked by uid 22791); 8 Apr 2011 15:48:41 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Apr 2011 15:48:36 +0000 Received: by vws2 with SMTP id 2so3436353vws.20 for ; Fri, 08 Apr 2011 08:48:35 -0700 (PDT) Received: by 10.52.74.106 with SMTP id s10mr3455100vdv.150.1302277715212; Fri, 08 Apr 2011 08:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.162.8 with HTTP; Fri, 8 Apr 2011 08:47:55 -0700 (PDT) In-Reply-To: <4D9F13E9.7000106@redhat.com> References: <4D95909E.4060309@redhat.com> <4D959C24.8030408@redhat.com> <238A96A773B3934685A7269CC8A8D04272EFEFD5C3@GVW0436EXB.americas.hpqcorp.net> <4D997D8C.9060903@redhat.com> <4D9993D4.9040704@redhat.com> <4D9ADA89.8000307@redhat.com> <4D9B112B.6000408@redhat.com> <4D9CB200.2000103@redhat.com> <4D9F13E9.7000106@redhat.com> From: Erik Groeneveld Date: Fri, 08 Apr 2011 15:48:00 -0000 Message-ID: Subject: Re: GC leaks debugging To: Andrew Haley Cc: java@gcc.gnu.org, "Boehm, Hans" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/msg00039.txt.bz2 >> The last good dump I have from the test after 12 million cycles (it >> then got killed) has nothing like File stuff at all. =C2=A0A also saw ot= her >> suspicious objects, but they all disappeared later on. =C2=A0The collect= er >> really works wel! >> >> Next hypothesis: >> From analyzing graphs from the logs and comparing them to those of the >> OpenJDK, I get the feeling that the collector looses control by not >> collecting often enough. >> >> The heap is quite unused/free, and remains so during the process. =C2=A0= It >> seems that at some point, the heap fills up very quickly, and then the >> collector decides to expand the heap instead of collecting (the >> algorithm for deciding this seems rather complicated). =C2=A0However, a >> larger heap also causes the collector to collect less frequently. =C2=A0= So >> the next time the heap fills up rapidly, it again decides to expand >> the heap, again causing less frequent collections. =C2=A0And so on. =C2= =A0I=C2=B4ll >> post the graph data in a separate post if you want it. > > That makes sense as an explanation. > > It looks, then, as though there isn't a leak at all. =C2=A0The collector > does what it's supposed to do. =C2=A0There is always the risk of this with > any non-compacting dynamic memory allocator. Yes, a non-moving collector has its limits, but I have still hope for improvement. >> And the next hypothesis: >> Perhaps the program allocates many different (possibly large) sizes, >> which remain on the free list, but cannot be used because the next >> objects requested are slightly bigger. =C2=A0I have to study this somewh= at >> more. > > I wonder. > >> Just two questions: >> 1. What is a reasonable number of heap sections? =C2=A0I have 131 here. >> 2. What is a reasonable number of free lists? =C2=A0I have 60, which have >> 13,000+ entries. I found from the code that 60 is the upper bound. And 13,000 seems to be a lot to me. Altogether, the free space is about 700 Mb, of a 900 Mb heap. Hans, is there a limit on the length of the free lists? Adjacent blocks of the same size are coalesced; is there also coalescing of blocks of different sizes at some point? I tried a build with with USE_MUNMAP, hoping that would help the collector clean up free-list, but I am still testing. > Paging Hans Boehm. =C2=A0can you suggest ways to get the system to GC more > frequently? =C2=A0Would doing so avoid this scenario? > > Andrew. >