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: Thu, 23 Jun 2022 13:07:44 -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> <8335fvg8kz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b92ede05e2207e21" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23833"; 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 19:20:48 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 1o4QVc-00064v-18 for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 19:20:48 +0200 Original-Received: from localhost ([::1]:52870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4QVa-00004s-UJ for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 13:20:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4QJJ-0005lr-Ds for emacs-devel@gnu.org; Thu, 23 Jun 2022 13:08:05 -0400 Original-Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]:46773) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4QJD-000819-48; Thu, 23 Jun 2022 13:08:01 -0400 Original-Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-1013ecaf7e0so189335fac.13; Thu, 23 Jun 2022 10:07:58 -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=DP5Qg2Edtc7p+iZDOSioApwe9O60quVqWmJwhqOCpu0=; b=Cw0dsUnKrZQ0oa+T+WvxY0mFEbZtJHvv1QwVAI1QbkX2lEpNhY37N6r/wKEg5eMP07 lqpgnvG4Wgei/MNeJPuKu5mnmRy7JzNtd6F2FqawNrwx9A+/ua7CGQoO4Ni1rmEer8DE tWrzfQ9afVIU26a/UupABr6teNpMwhHsTTu0QTSS2atGXhK9IGE7nz/DFuuaM41cNLti SRi+l+DfgMCgm1wgBFX0pm2vJEIt/TRzqDDkOJ7poqenuU5kjQnFPZyxkLO1SLwDcOqc +KNezfHKr/IyrnnJBrwxZHGsjIUefDGVOvTJN3iG7zvDe+2h92qeJdMLy8PMIDtNgh4J NAVQ== 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=DP5Qg2Edtc7p+iZDOSioApwe9O60quVqWmJwhqOCpu0=; b=oJ6xlLoejrAdDC5bfHdgyjOBuWm4y530FMuv3ftID+ecKM/tpRPWq3u97/BftX2Q0U lAWDoU08BuT1iwgHjCfKkYYewDckpWfq6EYCjVtbvYHhoEm9b5z5c7N3DEEQYQbOvrOO J90T4Os8MQ3cZVQJSp1tJoRgqo99XNdiabgJRnUHvKL2c7rj9lf46KrDbF8SmTjk4eNA bYewro82DXRBSUDpEWm4lH2rfnES8iafAyCCa86xwhAPhi1LJkGGjaorqaURE2slUJdT F18SRFp7dw7uMpbpKcXU9ffnqQ4wO0xCyNv2enuLz3hTqEHk9dH3RAnHBTYjsTszj27r Yqqg== X-Gm-Message-State: AJIora+3SciQG+nSbhgYWL3l+9NgNiV8ES6ORmN+keMqT3bXjsayDZxp UUAjZ3SRbITg52xv9ycckqoudO2NGkzE96sP8PksGhXhXU4= X-Google-Smtp-Source: AGRyM1tWglCIoAO79J/I8R8inhh488fTetwe4K1pFeuWUrLVlEkp58APP1y8NjywZS3fPzU6welOWX7JZHOFBpAhWAc= X-Received: by 2002:a05:6870:d791:b0:101:ad64:1e74 with SMTP id bd17-20020a056870d79100b00101ad641e74mr3192512oab.162.1656004076448; Thu, 23 Jun 2022 10:07:56 -0700 (PDT) In-Reply-To: <8335fvg8kz.fsf@gnu.org> Received-SPF: pass client-ip=2001:4860:4864:20::2b; envelope-from=owinebar@gmail.com; helo=mail-oa1-x2b.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:291540 Archived-At: --000000000000b92ede05e2207e21 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 23, 2022 at 3:09 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > 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. > > We lack someone in the role of the "project historian", who would then > summarize and publish the design discussions in the form of such > notes. Volunteers are most welcome. > It's not the discussion (or history) per se, but the factors that decided the current design choices. An example would be the #ifdef DOUG_LEA_MALLOC blocks in lisp_align_malloc of alloc.c that prevent allocating via mmap. So far what I've read indicates that step is there to enable dumping by unexec (assuming I've understood correctly). Ideally there would be a design note (possibly generated from comments, possibly free standing) that would explain what the purpose of the restriction is, so you could tell if it's still relevant, and any negative impacts it has. Also, if there are plans to remove it at some point, what (if any) the requirements/test for removing it would be, etc. By "it", I mean any hypothetical design point, not just this particular one. Alternative designs could also be discussed along with the factors that led to their rejection, if it was significant enough. Now, those could be derived from mailing list discussions, but I wouldn't consider them "history". Per subsequent mails in this thread, if a developer or code reviewer made a practice of citing particular mail messages (or even other sources), some extraction process might even be automated, but then there would be the question of copyright assignment. It would help if there were some taxonomy of features/design points for reference. Is the bug database being used for that? Actually, a good example (even though it's more post facto description than prospective design & cost-benefit tradeoff analysis) would be https://github.com/rocky/elisp-bytecode That is really useful documentation that would ideally be in the emacs docs or etc directory. Andrea's development log and paper on the compiler are another example. The development log would benefit (in terms of use as design notes) from de-chronologizing them, figuring out the right taxonomy of the various topics, and gathering the material accordingly. I put in a request to assign@gnu.org a few days ago, but I have not received any response yet. > > > 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. > > A better method is to use Git logs to find when the GNU/Linux build > stopped using mmap, and then search the archives around that time. > > > I will say jemalloc appears to have a lot of heap profiling bells and > whistles. > > AFAIU, so does glibc. Some of them where mentioned in the discussions > you already unearthed, AFAIR. > I figured it would. jemalloc's maintainers just spend a lot of effort highlighting those features in the documentation. I wouldn't be surprised if it was 3/4 of the material on the package's site is dedicated to how to use jemalloc's profiling for debugging or optimizing memory allocation in the calling program. It makes an impression. Lynn --000000000000b92ede05e2207e21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23, 2022 at 3:09 AM Eli Zaret= skii <eliz@gnu.org= > wrote:
> From: Lynn Winebarger <owinebar@gmail.com>
> Not t= hat I don't enjoy trawling through old threads in the emacs-devel archi= ve
> (searching for mmap led to a thread from the introduction of the porta= ble dumper),
> but it would be a lot easier if there were design notes somewhere reco= rding
> the rationale of the decisions reflected in the current code.

We lack someone in the role of the "project historian", who would= then
summarize and publish the design discussions in the form of such
notes.=C2=A0 Volunteers are most welcome.

It's not the discussion (or history) per se, but the factors that de= cided the current
design choices.=C2=A0 An example would be the #= ifdef DOUG_LEA_MALLOC blocks in lisp_align_malloc
of alloc.c that= prevent allocating via mmap.=C2=A0 So far what I've read indicates
that step is there to enable dumping by unexec (assuming I've un= derstood correctly).
Ideally there would be a design note (possib= ly generated from comments, possibly free standing)
that would ex= plain what the purpose of the restriction is, so you could tell if it's= still
relevant,=C2=A0and any negative impacts it has.=C2=A0 Also= , if there are plans to remove it at=C2=A0
some point, what (if a= ny) the requirements/test for removing it would be, etc.=C2=A0 By "it&= quot;,
I mean any hypothetical design point, not just this partic= ular one.
Alternative designs could also be discussed along with = the factors that led=C2=A0
to their rejection, if it was signific= ant enough.
Now, those could be derived from mailing list discuss= ions, but I wouldn't consider them
"history".=C2=A0= Per subsequent mails in this thread, if a developer or code reviewer made= =C2=A0
a practice of citing particular mail messages (or even oth= er sources), some extraction=C2=A0
process might even be automate= d, but then there would be the question of copyright=C2=A0
assign= ment.=C2=A0 It would help if there were some taxonomy of features/design po= ints for=C2=A0
reference.=C2=A0 Is the bug database being used fo= r that?

Actually, a good example (even though it&#= 39;s more post facto description than prospective
design & co= st-benefit tradeoff analysis) would be=C2=A0https://github.com/rocky/elisp-bytec= ode
That is really useful documentation that would ideally be= in the emacs docs or etc directory.
Andrea's development log= and paper on the compiler are another example.=C2=A0=C2=A0
The d= evelopment log would benefit (in terms of use as design notes) from de-chro= nologizing
them, figuring out the right taxonomy of the various t= opics, and gathering the material accordingly.

I p= ut in a request to assign@gnu.org a f= ew days=C2=A0ago, but I have not received any response yet.
=C2= =A0

> The best I can do now
> is comb through the arguments on the list (and maybe in the bug tracke= r?) and
> try to guess which points ended up getting reflected in the code.

A better method is to use Git logs to find when the GNU/Linux build
stopped using mmap, and then search the archives around that time.

> I will say jemalloc appears to have a lot of heap profiling bells and = whistles.

AFAIU, so does glibc.=C2=A0 Some of them where mentioned in the discussions=
you already unearthed, AFAIR.

I figured= it would.=C2=A0 jemalloc's maintainers just=C2=A0spend a lot of effort= highlighting those features in the
documentation.=C2=A0 I wouldn= 't be surprised if it was 3/4 of the material on the package's site=
is dedicated to how to use jemalloc's=C2=A0profiling for deb= ugging or optimizing
memory allocation in the calling program.=C2= =A0 It makes an impression.

Lynn=C2=A0
<= br>
--000000000000b92ede05e2207e21--