From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: emacs user Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Fri, 6 Jan 2012 11:58:35 +0200 Message-ID: References: <71677AF5-0EE7-426E-B8FA-C2782B3CC36C@swipnet.se> <6F8FEE75-2ED4-45A7-85B9-305EE51B5A04@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1325843929 20600 80.91.229.12 (6 Jan 2012 09:58:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 09:58:49 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 06 10:58:45 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rj6ZP-0004FX-CM for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2012 10:58:43 +0100 Original-Received: from localhost ([::1]:60065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj6ZP-0001dV-1f for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2012 04:58:43 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:50855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj6ZK-0001ce-Ro for emacs-devel@gnu.org; Fri, 06 Jan 2012 04:58:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rj6ZI-0000D0-Vy for emacs-devel@gnu.org; Fri, 06 Jan 2012 04:58:38 -0500 Original-Received: from mail-wi0-f169.google.com ([209.85.212.169]:37874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj6ZI-0008Uv-Hv for emacs-devel@gnu.org; Fri, 06 Jan 2012 04:58:36 -0500 Original-Received: by mail-wi0-f169.google.com with SMTP id hq12so1382756wib.0 for ; Fri, 06 Jan 2012 01:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YvNCqIx2fSSvH2KdWIpKfFkNJlcRJjg6CUOPiomsCyY=; b=pqhEk+6bj55ipGlqH8kA6z+UY2Cvzsf/igncjOnA0Pr7Cc43i9yRzM2nG8IAyFHNWw in9BwDiCIz/l7d9auX3p6n9zTOdJhtQ/4ozhfNxLxqZ1j2+QhpFwzuR6IQUJpN7212jD 6fR68oEQNm1A3CaDxezwXUkSGkdIV8B7iuB+Y= Original-Received: by 10.180.107.134 with SMTP id hc6mr10087104wib.21.1325843915568; Fri, 06 Jan 2012 01:58:35 -0800 (PST) Original-Received: by 10.216.170.138 with HTTP; Fri, 6 Jan 2012 01:58:35 -0800 (PST) In-Reply-To: <6F8FEE75-2ED4-45A7-85B9-305EE51B5A04@swipnet.se> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147393 Archived-At: things seem to be a bit better with aquamacs 2.4, where some memory is retu= rned. On Fri, Jan 6, 2012 at 12:37 AM, Jan Dj=E4rv wrote: > Hello. > > I see this increase also. =A0Memory does not seem to be given back to the= system on OSX. > Maybe we should try using gmalloc on OSX. =A0There is problem however, th= e unexec for OSX > uses a special malloc for temacs and the normal one for the dumped emacs.= =A0I'm not even sure gmalloc > works on OSX. > > =A0 =A0 =A0 =A0Jan D. > > 5 jan 2012 kl. 07:13 skrev emacs user: > >> On Fri, Dec 23, 2011 at 12:44 PM, emacs user wrot= e: >>> On Fri, Dec 23, 2011 at 2:39 AM, Stefan Monnier >>> >>>> The GC stats you posted indicate that the GC knows of about 27MB of da= ta >>>> (10MB of which is actually unused but can't be returned to malloc due = to >>>> fragmentation) which doesn't account for the 214MB you mention. =A0So = it >>>> looks like that data is held by the C code. >>>> >>>> Of course, I don't know what the 214MB represent, if it is resident se= t >>>> size, then there really seems to be a leak, whereas if it's the total >>>> virtual size, it may also be an artifact of various other things. >>>> >>>> >>>> =A0 =A0 =A0 =A0Stefan >>> >>> here is something which I am hoping is reproducible by others: >>> download >>> http://emacsforosx.com/emacs-builds/Emacs-2011-12-23-universal-10.6.8.d= mg >>> save to desktop. >>> >>> start emacs: >>> $ ~/Desktop/Emacs.app/Contents/MacOS/Emacs -Q& >>> >>> create a file that contains the following line many times >>> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf a= sdf >>> $ wc t : =A0687456 10311840 52246656 t >>> $ ls -l t: -rw------- =A01 x =A0staff =A052246656 Dec 23 05:08 t >>> >>> edit it using the above emacs. >>> kill all buffers, do M-x garbage-collect >>> >>> look at the process: >>> >>> =A0$ ps -vefl | head -1 >>> =A0PID STAT =A0 =A0 =A0TIME =A0SL =A0RE PAGEIN =A0 =A0 =A0VSZ =A0 =A0RS= S =A0 LIM =A0 =A0 TSIZ >>> %CPU %MEM COMMAND =A0 =A0 =A0 =A0 =A0 =A0UID =A0PPID =A0 C STIME =A0 TT= Y =A0 =A0 =A0 =A0 =A0 =A0 F >>> PRI NI WCHAN =A0 =A0 =A0 =A0 =A0 =A0 =A0ADDR >>> >>> before editing the file: >>> $ ps -vefl | grep 62764 >>> 62764 S =A0 =A0 =A00:00.78 =A0 0 =A0 0 =A0 =A0 =A00 =A02571020 =A030852= =A0 =A0 - =A0 =A0 =A0 =A00 >>> 0.3 =A00.7 /Users/xxx/Deskt =A0 501 62068 0 5:38AM ttys001 =A0 =A0 =A04= 006 >>> 49 =A00 - =A0 =A0 =A0ffffff8012762000 >>> >>> after editing it, killing the buffer, and doing M-x garbage-collect >>> =A0$ ps -vefl | grep 62764 >>> 62764 S =A0 =A0 =A00:01.85 =A0 0 =A0 0 =A0 =A0 =A00 =A02625752 =A083036= =A0 =A0 - =A0 =A0 =A0 =A00 >>> 0.6 =A02.0 /Users/xxx/Deskt =A0 501 62068 0 5:38AM ttys001 =A0 =A0 =A04= 006 >>> 48 =A00 - =A0 =A0 =A0ffffff8012762000 >>> >>> I am running on Lion, Macbook Air. =A0does this help? >> >> just in case this is helpful, I see the same increase in RSS using >> emacs 23.3 too, but not under linux. =A0is this a problem, or is this >> increase in RSS normal? >