From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14280 invoked by alias); 10 Apr 2011 11:03:56 -0000 Received: (qmail 14271 invoked by uid 22791); 10 Apr 2011 11:03:54 -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; Sun, 10 Apr 2011 11:03:50 +0000 Received: by vws2 with SMTP id 2so4489303vws.20 for ; Sun, 10 Apr 2011 04:03:49 -0700 (PDT) Received: by 10.52.176.134 with SMTP id ci6mr6115857vdc.190.1302433429163; Sun, 10 Apr 2011 04:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.162.8 with HTTP; Sun, 10 Apr 2011 04:03:09 -0700 (PDT) In-Reply-To: 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> <238A96A773B3934685A7269CC8A8D04272F0041802@GVW0436EXB.americas.hpqcorp.net> From: Erik Groeneveld Date: Sun, 10 Apr 2011 11:03:00 -0000 Message-ID: Subject: Re: GC leaks debugging To: "Boehm, Hans" Cc: Andrew Haley , "java@gcc.gnu.org" 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/msg00045.txt.bz2 On Sat, Apr 9, 2011 at 12:55 PM, Erik Groeneveld wrote: > On Sat, Apr 9, 2011 at 3:14 AM, Boehm, Hans wrote: > > I only kept the last dump of GC_DUMP_REGULARLY because they became GBs > big. =C2=A0It is attached. > >> That test program is pushing the envelope in a couple of different ways: >> >> 1. It potentially causes lots of fragmentation if some of those objects = are not immediately reclaimed. I wrote a little Python script to analyze the heap dump from GC_dump (attached earlier). It finds all large blocks like: 0x7f8198277000 size 180224 not black listed then sorts them on the address, and scans it all to see if they are adjacen= t. None of the 13,000+ blocks are. It also calculates the gaps between the blocks and adds them. It leaves out the 13 largest gaps as they are likely to represent different heap sections and not GC allocated space. It adds up to 296 Mb, roughly the amount of space in use by the program according to GC_dump, 273 Mb. So indeed there is a lot fragmentation... Any ideas about how to fight this? I believe that I am now able to revisit my earlier suspicion about the GC losing control by not collecting enough. If it did collect more often, it could avoid fragmentation. (Is that true?) But now, when fragmentation grows, it grows the heap and collects even less frequently, thus allowing for more fragmentation. And so on. It this a possible scenario? Erik