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:42:02 -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> <83funm5j1l.fsf@gnu.org> <83r375520w.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477323151 26058 195.159.176.226 (24 Oct 2016 15:32:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 15:32:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) Cc: 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:32:28 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 1byhEL-00047I-Ts for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 17:32:06 +0200 Original-Received: from localhost ([::1]:47450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byhEO-0000Fr-9E for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 11:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bygS2-0007m5-OO for emacs-devel@gnu.org; Mon, 24 Oct 2016 10:42:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bygS1-0002GW-TX for emacs-devel@gnu.org; Mon, 24 Oct 2016 10:42:10 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:27906) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bygRw-0002CS-98; Mon, 24 Oct 2016 10:42:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHAgALW9BX/++F+M5dGwEBAQMBAQGDLQEBAQEBHoRNhVCEZasRggOGFgQCAoFpORQBAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0kLognCLxVAQEIAiWKfYocAQSZWZkNhguPDYE+HjaCaBuBaSCGCgEBAQ X-IPAS-Result: A0BHAgALW9BX/++F+M5dGwEBAQMBAQGDLQEBAQEBHoRNhVCEZasRggOGFgQCAoFpORQBAgEBAQEBAQFeJ4RiAQEDAVYjBQsLNBIUGA0kLognCLxVAQEIAiWKfYocAQSZWZkNhguPDYE+HjaCaBuBaSCGCgEBAQ X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="276928915" 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:42:03 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 57EE16622D; Mon, 24 Oct 2016 10:42:02 -0400 (EDT) In-Reply-To: <83r375520w.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Oct 2016 16:07:11 +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:208693 Archived-At: > I don't understand how you get to talking about fragmentation. I > never mentioned anything like that. The problems I was talking about > are all related to using ralloc.c on GNU/Linux systems with a recent > enough glibc. I misunderstood, then. I fully agree that ralloc.c is a landmine, if that's what you meant. That's why I think we should get rid of it. And if we really want to keep it, we should prefer mmap over ralloc (i.e. we should only consider ralloc in those cases where the mmap alternative is unavailable (not sure if there are still systems where this is the case, the DOS port maybe?)). AFAIK, gmalloc+mmap-ralloc is a perfectly acceptable solution for Emacs-25.2 with the new glibc, with no known problem. Stefan