From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Mon, 24 Oct 2016 23:12:40 -0400 Message-ID: References: <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <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 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1477365213 18345 195.159.176.226 (25 Oct 2016 03:13:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 03:13:33 +0000 (UTC) To: Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 05:13:29 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 1bysAv-0002s5-QJ for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 05:13:17 +0200 Original-Received: from localhost ([::1]:51393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bysAy-0000mW-8V for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 23:13:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bysAQ-0000mE-LR for emacs-devel@gnu.org; Mon, 24 Oct 2016 23:12:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bysAN-0005UZ-Gk for emacs-devel@gnu.org; Mon, 24 Oct 2016 23:12:46 -0400 Original-Received: from mail-qt0-x235.google.com ([2607:f8b0:400d:c0d::235]:39631) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bysAN-0005U7-Bg for emacs-devel@gnu.org; Mon, 24 Oct 2016 23:12:43 -0400 Original-Received: by mail-qt0-x235.google.com with SMTP id g49so6104764qtc.6 for ; Mon, 24 Oct 2016 20:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nNw61P/mHsRIR/CZeKa5/wl1MDRK+/yrhNAirwOYyYI=; b=dU888bojztI4Hfw+PKvfrWwko1EtioKrp/CFxViCINO5VLc9lT1Id1V30LYSQF4+zL uRU1LtfK/+qrGFI1k1Ma5L0m+QmRROcc9S2sb+IznHkH5xJyWOuT3HCAOEfOoPAQzNkn jPTQqnNLdpl8djHWgWfRvSkb1otVZq4Cj48MpoH01CigeWiIGh3tdqlP1eIEjXcFuYYg paOoloUTjUbkskcnmI3KEifjtZkzQ46su4FXAV0OrrUSMBcvDn+pGK40WLAuNUumNsQY Phh6IdLU7NmXBN28dru1GLSDfcDXV0FU/NIu6Z91L2D+2TBRE6en2FMW1cBjoKUqWLGG C6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nNw61P/mHsRIR/CZeKa5/wl1MDRK+/yrhNAirwOYyYI=; b=Dd/OFJCAYsfenRLWOGhgcdy30yvgJV9nSrUdwfqK2bZ33Jau8R9Bl9wRvQUxLS6tDV LKlmBEPaM4x6gFQIvFVzQVQ+UZK2snEBaCbshDDQIdmi+IvjCZO0z+t8N/Ebl++s3R+Q e0q/pNDNNdtu4MgM0at03XcbqwCXC/j1H8hLeKQm7Pd6d1XFefjAnNDheEXMmqVsHfN7 Ae66UPvvuWT6p8GRgSToi8/OHigTnKXwmUeA+z57RGMekPUU7sjy9v8bfdkz89Cj12xK pyAgtpoxGAC9CXgZEJHRG6iICVjxxZXLQ1PCFeIYydGlwyUPyOCiy7cxfjsf99lElyDm MSUQ== X-Gm-Message-State: ABUngveTMcS/pYlb+XNkaQIC2T438kaSyWZuUi+eXZAlr4uct5htfqEIPP365MSN1TG99g== X-Received: by 10.200.50.157 with SMTP id z29mr17593327qta.11.1477365162429; Mon, 24 Oct 2016 20:12:42 -0700 (PDT) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id y126sm10041454qkb.37.2016.10.24.20.12.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 24 Oct 2016 20:12:41 -0700 (PDT) In-Reply-To: <83shrl523p.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c0d::235 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:208750 Archived-At: On Oct 24, 2016, at 09:05, Eli Zaretskii wrote: > 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. This happens quite a lot when we visit a compressed > buffer. (The MS-Windows emulation of mmap in w32heap.c reserves twice > the number of pages as originally requested, for that very reason.) In the general case, yes. But modern Linux kernels have an =E2=80=9Cmrema= p=E2=80=9D system call which can =E2=80=9Cmove=E2=80=9D a range of pages = to a portion of the address space that can accommodate a larger size, by = tweaking page tables rather than copying all the bits around. I=E2=80=99m= pretty sure modern glibc realloc uses it. I had a project a while back = where code ported to Solaris ran far slower than the GNU/Linux version = because lots of realloc calls were done on a large array; Solaris = copied, GNU/Linux remapped. void *mremap(void *old_address, size_t old_size, size_t new_size, int flags, ... /* void *new_address */); Of course you can=E2=80=99t shift bytes within a page this way, or add = new space anywhere but after the last page of the old region. (No hint = in the man page whether you can use an explicit new address range = overlapping the old range to shift a chunk of memory a la memmove, or if = the results would be undefined a la memcpy.) I don=E2=80=99t know if any other systems support it. The performance = savings for one of our favorite systems might be worth the = special-casing. Though, if glibc realloc does the right thing, maybe = using malloc/realloc for buffer storage would suffice. Ken=