From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Mon, 24 Oct 2016 10:37:19 -0400 Message-ID: References: <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <838ttfnmev.fsf@gnu.org> <837f8znk8f.fsf@gnu.org> <83zilvm2ud.fsf@gnu.org> <83r377m0i8.fsf@gnu.org> <83eg36n6v5.fsf@gnu.org> <83shrl523p.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477324014 16695 195.159.176.226 (24 Oct 2016 15:46:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 15:46:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 17:46:49 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byhSG-0001Jf-2h for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 17:46:28 +0200 Original-Received: from localhost ([::1]:47591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byhSI-0004u7-Ar for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 11:46:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bygNS-0003eT-LL for emacs-devel@gnu.org; Mon, 24 Oct 2016 10:37:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bygNR-00005j-RM for emacs-devel@gnu.org; Mon, 24 Oct 2016 10:37:26 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43465) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bygNO-0008Vz-1u; Mon, 24 Oct 2016 10:37:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHAgALW9BX/++F+M5dGwEBAQMBAQGDLQEBAQEBHoRNhVCEZasRggOGFgQCAoFpORQBAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0QAROIVQi8VQEBCAIlin2KHAEEmVmZDYYLjw2BPh42hGwghgoBAQE X-IPAS-Result: A0BHAgALW9BX/++F+M5dGwEBAQMBAQGDLQEBAQEBHoRNhVCEZasRggOGFgQCAoFpORQBAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0QAROIVQi8VQEBCAIlin2KHAEEmVmZDYYLjw2BPh42hGwghgoBAQE X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="276928284" Original-Received: from 206-248-133-239.dsl.teksavvy.com (HELO ceviche.home) ([206.248.133.239]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Oct 2016 10:37:20 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id ECABF6622D; Mon, 24 Oct 2016 10:37:19 -0400 (EDT) In-Reply-To: <83shrl523p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Oct 2016 16:05:30 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208694 Archived-At: > Using mmap has disadvantages: when you need to enlarge buffer text, > and that fails (because there are no more free pages/addresses after > the already allocated region), we need to copy buffer text to the new > allocation. All allocators suffer from this problem. I haven't seen any evidence that the mmap-based allocation code is significantly more prone to it. Also, the glibc allocators used mmap internally when allocating large-ish chunks (e.g. for buffer text), so if that was a problem, we would have noticed, I think. > (The MS-Windows emulation of mmap in w32heap.c reserves twice the > number of pages as originally requested, for that very reason.) Indeed, if this problem proves significant, there are fairly easy ways to reduce its impact, such as using the kind of approach you mention. Another advantage of using mmap is that it can return the memory to the OS once you kill your large buffer, whereas with gmalloc+ralloc this basically never happens, AFAIK. Stefan