From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19933 invoked by alias); 4 Apr 2011 08:53:48 -0000 Received: (qmail 19921 invoked by uid 22791); 4 Apr 2011 08:53:47 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,TW_GC X-Spam-Check-By: sourceware.org Received: from mail-vx0-f175.google.com (HELO mail-vx0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Apr 2011 08:53:12 +0000 Received: by vxd7 with SMTP id 7so4894634vxd.20 for ; Mon, 04 Apr 2011 01:53:12 -0700 (PDT) Received: by 10.52.166.225 with SMTP id zj1mr4714474vdb.162.1301907192087; Mon, 04 Apr 2011 01:53:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.167.34 with HTTP; Mon, 4 Apr 2011 01:52:31 -0700 (PDT) In-Reply-To: <4D997D8C.9060903@redhat.com> References: <4D95909E.4060309@redhat.com> <4D959C24.8030408@redhat.com> <238A96A773B3934685A7269CC8A8D04272EFEFD5C3@GVW0436EXB.americas.hpqcorp.net> <4D997D8C.9060903@redhat.com> From: Erik Groeneveld Date: Mon, 04 Apr 2011 08:53:00 -0000 Message-ID: Subject: Re: GC leaks debugging To: Andrew Haley Cc: 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/msg00018.txt.bz2 On Mon, Apr 4, 2011 at 10:13 AM, Andrew Haley wrote: > On 03/04/11 18:59, Erik Groeneveld wrote: >> On Sun, Apr 3, 2011 at 7:14 PM, Erik Groeneveld wrote: >>> On Sat, Apr 2, 2011 at 11:38 AM, Erik Groeneveld wrote: >>>> >>>>> Note that in the information you posted, the GC was scanning around 7= .5MB of roots conservatively. =C2=A0It might be worth checking what those r= egions 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. =C2=A0The GC calls back -- the last arg being the size: >> >> _Jv_GC_has_static_roots(../gccinstall/lib/libgcj.so.12, 0xb704f000, 7544= 028) >> >> 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. =C2=A0Every class and every method has > this, and it can get to be quite large. I saw the (old) patch of yours that moves static Java objects onto the heap, avoiding it to be scanned conservatively, so I couldn't think of anything else to be on the static data area of libgcj than Java pointers to the objects heap. Now I see that there is still a lot more data that must be scanned conservatively, so couldn't there be similar problems as back then? Couldn't it be an idea to try to move this introspection data to the heap as well? > I doubt it's the cause of > your memory leak unless there's a bug elsewhere. Probably there is no clear bug, or clear leak, perhaps just a matter of pushing the GC to the limits? Some code is running quite well for long times, other isn't. I all cases, the heap grows very fast, with lots of black listing messages, and sometimes the GC just seems to manage, sometimes it doesn't and things explode while issuing the famous "need to allocate large block etc" repeatedly. From what Hans suggested and from what I see in the logs, the GC is under very heavy stress, right from the beginning. It doesn't get a fair chance so to say. My minimal program is now this: int main(int argc, char *argv[]) { _Jv_InitGC(); } It starts out with: roots: 7,072 kB heap: 64 kB free: 64 kB blacklisted: 15/16 blacklist messages: 991 Any real program produces so much blacklist messages that it hardly runs. I'd like to investigate this or am I on the wrong track completely? Erik > > Andrew. >