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:37:44 +0400 Message-ID: <4ED123E8.8000309@yandex.ru> References: <4ED0F945.5090805@yandex.ru> <83r50v6itk.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1322329057 21956 80.91.229.12 (26 Nov 2011 17:37:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2011 17:37:37 +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:37:33 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 1RUMBv-000795-Of for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 18:37:31 +0100 Original-Received: from localhost ([::1]:50782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUMBv-0004MG-9o for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 12:37:31 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUMBt-0004MB-96 for emacs-devel@gnu.org; Sat, 26 Nov 2011 12:37:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUMBs-0001bp-6i for emacs-devel@gnu.org; Sat, 26 Nov 2011 12:37:29 -0500 Original-Received: from mail-bw0-f41.google.com ([209.85.214.41]:42173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUMBr-0001bj-Rv for emacs-devel@gnu.org; Sat, 26 Nov 2011 12:37:28 -0500 Original-Received: by bke17 with SMTP id 17so6705184bke.0 for ; Sat, 26 Nov 2011 09:37:26 -0800 (PST) Original-Received: by 10.205.137.140 with SMTP id io12mr29991405bkc.120.1322329046474; Sat, 26 Nov 2011 09:37:26 -0800 (PST) Original-Received: from [192.168.0.171] ([78.153.153.8]) by mx.google.com with ESMTPS id j9sm22265808bkd.2.2011.11.26.09.37.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Nov 2011 09:37:26 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 In-Reply-To: <83r50v6itk.fsf@gnu.org> 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:146263 Archived-At: On 11/26/2011 06:48 PM, Eli Zaretskii wrote: >> This is an internal heap fragmentation, the most common disadvantage >> of simple mark and sweep GC. > > I don't think buffers are subject to this disadvantage, because they > are relocated when needed. Maybe I'm missing something, but please > elaborate to show what that is. IIUC, buffer _text_ might be relocated if it can't be enlarged 'in place'. If buffer text is already mmap()ed and grows even more, this doesn't affect the heap allocated with sbrk(). Buffer itself ('struct buffer') can't be relocated, as well as all other Lisp objects. Dmitry