From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Wed, 22 Jun 2022 19:30:20 -0400 Message-ID: References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> <83k098kg6c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000374c8505e211b953" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15005"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Stefan Monnier , Ihor Radchenko , =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= , Tim Cross , rms@gnu.org, Alan Mackenzie , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 23 01:31:59 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o49pG-0003iH-SF for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 01:31:58 +0200 Original-Received: from localhost ([::1]:35260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o49pF-00069B-HP for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Jun 2022 19:31:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o49ny-00056r-Vt for emacs-devel@gnu.org; Wed, 22 Jun 2022 19:30:39 -0400 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:43696) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o49nx-0002qj-2Q; Wed, 22 Jun 2022 19:30:38 -0400 Original-Received: by mail-ot1-x336.google.com with SMTP id a8-20020a05683012c800b0060c027c8afdso14190937otq.10; Wed, 22 Jun 2022 16:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fvE/HEPLHL1nbNrDcniyzPQI0Uptu6djGjRH9G4sLk0=; b=HPoRWpW1ubGw1g8H+A2YiroQxVQe8d8fM0lkadiT6E2Y4+QdL/Oq1osVvktDXa7i0L QRokFnXjLD4eUD9XJ/DN+uF3Y9p4F37Sb8d3ZRaR2MyIxHiBh+ceS3E9ahqhNJY4WcMm k4HLSfpm97bWszf/bTiwMQGUPreqCeddKq+mTR93KTGnkXAmvQ2az86do+P99YCGw+9f GAAn79BNgiLPz7fpnzk5fUuTH/pSIwchMkEcqBop41j8zH4STgNIvHXIDMg1AMGybtxv wQsjWy12XJYLTFetGcJVXGjUXS+8h3dj4lubtnd1G4RDc2icnlO/ZpiJP6q7yYAy3e3c tBDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fvE/HEPLHL1nbNrDcniyzPQI0Uptu6djGjRH9G4sLk0=; b=ciRYEWBtim0f/JbLJtC9D5ejlgV5ZW+nLyGVOHnUmmS1pxqVab0tnrS2pbSqiAUWdz 0SL+cQc/po4b5syve4tAcmmeP2LDsTusJGPEttSeII7Zo6z5H4QkCmwWszjVfhE/WIbD 7c8ZN+glPr1Do98E0RveKEZw6rWuVll2KCcT5ET1CSVBXfbTh/i1O0VAjXL3oY5hURSl TXdiuuE/CSV9cTvpilZuIwHFG7biSa2j/gZyyZwYKaSRBTn7f2P+KFe74jMNiyKkSoRE C+s6CQA3rxxwuYLuDEdrXIIpMA2uxhxfslJ0qOXmjfbrfaWgQsoAWYTmy4LXV1Badq8c I+PA== X-Gm-Message-State: AJIora/wdreJAEgWAeb/nue/2VWz6M7CEofMYOXh3oRZuFKdJvRoFAmN c9RNWJnfooxBIrF9VI8lwbFO2lOHswZTd40pvJagzFbTJsM= X-Google-Smtp-Source: AGRyM1u/OsW8Xfier29ptV6A/iIaOvhHap3nr9H1bWf6hZBD9eSLT/pq4TuZFTuPBB30OouWuUcFhj2dTQJF0nTuIxw= X-Received: by 2002:a9d:6b8b:0:b0:60e:25de:eccb with SMTP id b11-20020a9d6b8b000000b0060e25deeccbmr2434481otq.5.1655940633282; Wed, 22 Jun 2022 16:30:33 -0700 (PDT) In-Reply-To: <83k098kg6c.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=owinebar@gmail.com; helo=mail-ot1-x336.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291518 Archived-At: --000000000000374c8505e211b953 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 22, 2022 at 8:59 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Tue, 21 Jun 2022 20:01:43 -0400 > > Cc: Eli Zaretskii , Stefan Monnier < > monnier@iro.umontreal.ca>, > > Ihor Radchenko , Mattias Engdeg=C3=A5rd < > mattiase@acm.org>, > > Tim Cross , rms@gnu.org, Alan Mackenzie < > acm@muc.de>, > > emacs-devel > > > > For some reason, the configure script chooses not to use mmap for mallo= c. > > The configure script chooses not to use mmap directly because glibc's > malloc already does that internally where it decides that to be > beneficial, and because using mmap directly has some disadvantages > we'd like to avoid if possible. > > > jemalloc is designed to use mmap as much as possible > > So is glibc. > Wow, so it is - when I tried the same test without jemalloc, both 28.1 and 24.3 gave similar results. I must have misinterpreted the behavior of edebug's trace-buffer as being similar to issues I've had previously (probably due to not using an explicit garbage-collect, or killing rather than deleting text with undo disabled). Maybe I just buried the trace buffer instead of killing it. > so it isn't limited to freeing only the uppermost regions. > > Neither is glibc, although it uses different algorithms. > > > I can't tell what (if any) option allows me to overrule the configure > > scripts decision to use sbrk instead of mmap. > > You don't want that, not on GNU/Linux systems. We switched away of > sbrk and mmap for several good reasons. > Not that I don't enjoy trawling through old threads in the emacs-devel archive (searching for mmap led to a thread from the introduction of the portable dumper), but it would be a lot easier if there were design notes somewhere recording the rationale of the decisions reflected in the current code. The best I can do now is comb through the arguments on the list (and maybe in the bug tracker?) and try to guess which points ended up getting reflected in the code. I will say jemalloc appears to have a lot of heap profiling bells and whistles. --000000000000374c8505e211b953 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 22, 2022 at 8:59 AM Eli Zaretskii= <eliz@gnu.org>= wrote:
> Fro= m: Lynn Winebarger <owinebar@gmail.com>
> Date: Tue, 21 Jun 2022 20:01:43 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Ihor Radchenko <yantar92@gmail.com>, Mattias Engdeg= =C3=A5rd <mattiase= @acm.org>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Tim Cross <theophilusx@gmail.com>, rms@gnu.org, Alan Mackenzie <acm@muc.de>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0emacs-devel <emacs-devel@gnu.org>
>
> For some reason, the configure script chooses not to use mmap for mall= oc.

The configure script chooses not to use mmap directly because glibc's malloc already does that internally where it decides that to be
beneficial, and because using mmap directly has some disadvantages
we'd like to avoid if possible.

> jemalloc is designed to use mmap as much as possible

So is glibc.

Wow, so it is - when I tri= ed the same test without jemalloc, both 28.1 and 24.3 gave
simila= r results.=C2=A0 I must have misinterpreted the behavior of edebug's tr= ace-buffer as
being similar to issues I've had previously (pr= obably due to not using an explicit=C2=A0
garbage-collect,=C2=A0 = or killing rather than deleting text with undo disabled).
Maybe I= just buried the trace buffer instead of killing it.

> so it isn't limite= d to freeing only the uppermost regions.

Neither is glibc, although it uses different algorithms.

> I can't tell what (if any) option allows me to overrule the config= ure
> scripts decision to use sbrk instead of mmap.

You don't want that, not on GNU/Linux systems.=C2=A0 We switched away o= f
sbrk and mmap for several good reasons.

Not=C2=A0that I don't enjoy trawling through=C2=A0old threads in the e= macs-devel archive=C2=A0
(searching for mmap led to a thread from the in= troduction of the portable dumper),
but it would be a lot easier = if there were design notes somewhere recording
the rationale of t= he decisions reflected in the current code.=C2=A0 The best I can do now
is comb through the arguments on the list (and maybe in the bug trac= ker?) and
try to guess which points ended up getting reflected in= the code.

I will say jemalloc appears to have a l= ot of heap profiling bells and whistles.=C2=A0
=C2=A0

=C2=A0
--000000000000374c8505e211b953--