From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Sat, 26 Nov 2011 21:54:08 +0400 Message-ID: <4ED127C0.4030904@yandex.ru> References: <4ED0F945.5090805@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1322330048 29290 80.91.229.12 (26 Nov 2011 17:54:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2011 17:54:08 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 18:54:02 2011 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 1RUMRs-0004M9-Ed for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 18:54:00 +0100 Original-Received: from localhost ([::1]:57797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUMRr-0007nI-PN for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 12:53:59 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUMRp-0007nD-N4 for emacs-devel@gnu.org; Sat, 26 Nov 2011 12:53:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUMRo-0004T3-Cs for emacs-devel@gnu.org; Sat, 26 Nov 2011 12:53:57 -0500 Original-Received: from mail-bw0-f41.google.com ([209.85.214.41]:61499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUMRo-0004Sx-6t for emacs-devel@gnu.org; Sat, 26 Nov 2011 12:53:56 -0500 Original-Received: by bke17 with SMTP id 17so6722978bke.0 for ; Sat, 26 Nov 2011 09:53:50 -0800 (PST) Original-Received: by 10.204.151.144 with SMTP id c16mr5209832bkw.45.1322330030311; Sat, 26 Nov 2011 09:53:50 -0800 (PST) Original-Received: from [192.168.0.171] ([78.153.153.8]) by mx.google.com with ESMTPS id fa8sm14065518bkc.14.2011.11.26.09.53.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Nov 2011 09:53:49 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.41 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:146264 Archived-At: On 11/26/2011 06:58 PM, Carsten Mattner wrote: > Allow me to be naive and ask this: what about compaction? Compaction implies the moving of live objects, which means that you should be able to find _all_ pointers to such objects and update them. Emacs GC has no such features, but it's technically possible to enhance mark/sweep GC to do some heap compaction. > Would the allocator in use fragment the overall system memory > space if it frees more aggressively? If you want to ask 'if we will run GC more often, will it reduce heap fragmentation', the answer is most probably 'no'. You can try to play with 'gc-cons-threshold' and 'gc-cons-percentage' and see what happens. But, in general, heap fragmentation issues can't be solved this way. Other possible meanings of 'more aggressively' makes no sense for simple (non-generational, non-incremental) mark/sweep GC since it _always _ marks all live data and _always_ sweeps the whole Lisp data regions of the heap. If you're looking for good introduction to GC stuff, I would recommend ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps. Dmitry