From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31059 invoked by alias); 15 Apr 2011 07:32:54 -0000 Received: (qmail 31044 invoked by uid 22791); 15 Apr 2011 07:32:53 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ey0-f175.google.com (HELO mail-ey0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Apr 2011 07:32:48 +0000 Received: by eye27 with SMTP id 27so757832eye.20 for ; Fri, 15 Apr 2011 00:32:47 -0700 (PDT) Received: by 10.213.29.142 with SMTP id q14mr2765424ebc.87.1302852767268; Fri, 15 Apr 2011 00:32:47 -0700 (PDT) Received: from [10.0.0.3] (82-170-156-43.ip.telfort.nl [82.170.156.43]) by mx.google.com with ESMTPS id r48sm1731561eei.23.2011.04.15.00.32.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 00:32:44 -0700 (PDT) References: <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> <4DA55ABC.1040505@redhat.com> <4DA6B3AD.7090508@redhat.com> <4DA6D14F.1080503@redhat.com> In-Reply-To: <4DA6D14F.1080503@redhat.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3EEDD501-73F7-4BC3-BA9B-E5FA4E6E4F73@cq2.nl> Cc: "java@gcc.gnu.org" From: Erik J Groeneveld Subject: Re: GC leaks debugging Date: Fri, 15 Apr 2011 07:32:00 -0000 To: Andrew Haley 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/msg00054.txt.bz2 Op 14 apr. 2011 om 12:49 heeft Andrew Haley het volgende g= eschreven: >>> Why do you want to munmap, anyway? Are you running out of swap space? >>=20 >> Well, I assume that if the GC unmaps a page (hblk), it can always be >> mapped at any other location when a new block is needed, effectively >> circumventing fragmentation completely. >=20 > AFAIK it just returns the memory to the OS; It turns out it doesn't. It remaps it as not accessible. And it is only doi= ng so after the block hasn't been used for a while.=20 And there is some complicated code that seems to remap all such blocks into= a larger block. > I don't think it affects > anything else. I am still hoping it does. ;-) Erik