From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <java-return-26860-listarch-java=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21981 invoked by alias); 4 Apr 2011 08:13:39 -0000
Received: (qmail 21964 invoked by uid 22791); 4 Apr 2011 08:13:37 -0000
X-SWARE-Spam-Status: No, hits=-6.5 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_GC,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Apr 2011 08:13:03 +0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p348D2eh006448	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)	for <java@gcc.gnu.org>; Mon, 4 Apr 2011 04:13:02 -0400
Received: from zebedee.pink (ovpn-113-109.phx2.redhat.com [10.3.113.109])	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p348D1oQ019630;	Mon, 4 Apr 2011 04:13:02 -0400
Message-ID: <4D997D8C.9060903@redhat.com>
Date: Mon, 04 Apr 2011 08:13:00 -0000
From: Andrew Haley <aph@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
To: java@gcc.gnu.org
Subject: Re: GC leaks debugging
References: <AANLkTim1XhyVMDOLpfSAM6QWMPmFDRz8vh-JgMpziPqR@mail.gmail.com> <4D95909E.4060309@redhat.com> <AANLkTikG2CBU8q2yde+NZLJ8x7Rcg2jHQG0Ojmc0g=ks@mail.gmail.com> <4D959C24.8030408@redhat.com> <238A96A773B3934685A7269CC8A8D04272EFEFD5C3@GVW0436EXB.americas.hpqcorp.net> <BANLkTim-j+s4ubQK9=tB=rKw7tKJovq6Uw@mail.gmail.com> <BANLkTinjau9wC4Fe36U7WMqP5n_+kEtdGA@mail.gmail.com> <BANLkTinPa=OE3EufbbwmXxXnjYF-idey7w@mail.gmail.com>
In-Reply-To: <BANLkTinPa=OE3EufbbwmXxXnjYF-idey7w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <java.gcc.gnu.org>
List-Id: <java.gcc.gnu.org>
List-Subscribe: <mailto:java-subscribe@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/java/>
List-Post: <mailto:java@gcc.gnu.org>
List-Help: <mailto:java-help@gcc.gnu.org>, <http://gcc.gnu.org/ml/#faqs>
Sender: java-owner@gcc.gnu.org
X-SW-Source: 2011-04/txt/msg00017.txt.bz2

On 03/04/11 18:59, Erik Groeneveld wrote:
> On Sun, Apr 3, 2011 at 7:14 PM, Erik Groeneveld <erik@cq2.nl> wrote:
>> On Sat, Apr 2, 2011 at 11:38 AM, Erik Groeneveld <erik@cq2.nl> wrote:
>>>
>>>> Note that in the information you posted, the GC was scanning around 7.5MB of roots conservatively.  It might be worth checking what those regions are.
> [...]
>> So I am now off into JvCreateJavaVM,
> 
> and I found that the 7.5 MB roots are the static data area of libgcj
> itself.  The GC calls back -- the last arg being the size:
> 
> _Jv_GC_has_static_roots(../gccinstall/lib/libgcj.so.12, 0xb704f000, 7544028)
> 
> and since libgcj is in 'the store' (_Jv_print_gc_store() prints
> "../gccinstall/lib/libgcj.so.12"), it tells the GC to scan its static
> data area conservatively.
> 
> As of yet I don't understand why this static area is so big, and what
> could be on it, but when I lay myself to rest, the little gray cells
> will sing to me (free after Hercules Poirot ;-).

It'll mostly be introspection data.  Every class and every method has
this, and it can get to be quite large.  I doubt it's the cause of
your memory leak unless there's a bug elsewhere.

Andrew.