From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Sat, 26 Nov 2011 22:19:03 +0200 Message-ID: <83obvy7i2w.fsf@gnu.org> References: <4ED0F945.5090805@yandex.ru> <83r50v6itk.fsf@gnu.org> <4ED123E8.8000309@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1322338757 21381 80.91.229.12 (26 Nov 2011 20:19:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2011 20:19:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 21:19:13 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 1RUOiO-0000D3-V7 for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 21:19:13 +0100 Original-Received: from localhost ([::1]:43317 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUOiO-0006LX-10 for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 15:19:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUOiL-0006LH-12 for emacs-devel@gnu.org; Sat, 26 Nov 2011 15:19:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUOiI-00019C-SL for emacs-devel@gnu.org; Sat, 26 Nov 2011 15:19:08 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUOiI-00018x-Kn for emacs-devel@gnu.org; Sat, 26 Nov 2011 15:19:06 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LVA00400AUAGF00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 26 Nov 2011 22:19:00 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.100.85]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVA003K4B3NBNI0@a-mtaout20.012.net.il>; Sat, 26 Nov 2011 22:19:00 +0200 (IST) In-reply-to: <4ED123E8.8000309@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:146269 Archived-At: > Date: Sat, 26 Nov 2011 21:37:44 +0400 > From: Dmitry Antipov > > 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. That's true, but the buffer text is by far the largest component of the buffer object. It is also the only one that changes its size, sometimes considerably, during the buffer's life.