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: Mon, 20 Jun 2022 08:42:05 -0400 Message-ID: References: <83bkuzznws.fsf@gnu.org> <877d5mqmkh.fsf@localhost> <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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000035a62605e1e06fda" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Ihor Radchenko , =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= , Eli Zaretskii , Tim Cross , rms@gnu.org, Alan Mackenzie , emacs-devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 20 14:44:05 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 1o3GlB-0007Vw-3o for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 14:44:05 +0200 Original-Received: from localhost ([::1]:36376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3GlA-0000JL-5H for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 08:44:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33594) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3GjW-0007or-6t for emacs-devel@gnu.org; Mon, 20 Jun 2022 08:42:22 -0400 Original-Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]:37886) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o3GjU-0004BA-H0; Mon, 20 Jun 2022 08:42:21 -0400 Original-Received: by mail-oi1-x22a.google.com with SMTP id h187so13482853oif.4; Mon, 20 Jun 2022 05:42:18 -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=/1vHUdyFl4Yf6xAZbRs59Bx1bSghuK+Li2UE63t3HY4=; b=O9EkMfzwgSVOsVINh8rG5PzwqnPKtwBp40N1Mdz7rMdGOEabZilhr89BhUeLn78RFJ UAVWxbxGnR1vy99LfeSMZ1GDe897JNsL4984wCnYhE/xsNBpMG/YCIOOCiilWTr5w7q5 /BV7SmmOyyTHM52IJCU8f02S8XtjK+NSad0mJqaPbFls2CiXK6JPFdNDkAyrSZzv/4Ky ygMMp9/Yt/XhqI/9MF9PPjx7PUzdNQm/WCZIOLpAMpOQfBKSLRAU1vk5HLGU4aFSfEEQ t+v7rGlAeafWQeGJO9dnnN4IgU42r0Et2MTPScAdaPA2cQljbKV4zhOH0+DvHaY0mQja jGmg== 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=/1vHUdyFl4Yf6xAZbRs59Bx1bSghuK+Li2UE63t3HY4=; b=D+T8IpGsvnxuj6MobQFHx8HQiMjzwI7a3TcQaTCt6zIuFpqOz+g1fBWneptIf2uAJ2 FjLrlanlduMUOiueCL4a5gbmBduVA7JXdxTu7A3VP5T3SkZtWjOYHlYpubBJnUX2w396 9WXCM3KszO9wh4XiJIwr/RrMBenTarxuJtnJHp4yHaTJtq1A4AvhQ+HrScZzqIY7Qpg6 K2zx13RPmDjEYn+6de97whI5SRfiqDBtTPMaRk8W3cqUT/itZOXWlbuB/XGgNpOqMYYJ y7U522fXotcfvKhNJ3kMd3AkBfNE9j66xMOYljE8Jw1vnGbqDETg8kOQh1AcOUVMTEqr rayA== X-Gm-Message-State: AJIora9H6Mt/5wek9tefMWaerPYI/VdfoenOvg6fsqRIuJhYmfKJ187X 0rJBrvU0Cs1PTLJiuuUCyZLwSwdMZvhKukcwBKg= X-Google-Smtp-Source: AGRyM1tl8QB4mMZUz4XvQ4/pnvM6qOnzHpI6Yoa6oQPpz9wOk4nvNzR07XhbLPaEgZJ0TjuN1O2ebQ3dyNLp9AouZew= X-Received: by 2002:a05:6808:144f:b0:32f:56f5:7754 with SMTP id x15-20020a056808144f00b0032f56f57754mr11766975oiv.162.1655728938262; Mon, 20 Jun 2022 05:42:18 -0700 (PDT) In-Reply-To: <871qvm16he.fsf@gnus.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::22a; envelope-from=owinebar@gmail.com; helo=mail-oi1-x22a.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:291466 Archived-At: --00000000000035a62605e1e06fda Content-Type: text/plain; charset="UTF-8" On Sat, Jun 18, 2022 at 8:52 AM Lars Ingebrigtsen wrote: > Stefan Monnier writes: > > As far as I know, we never actually release back cons space to the OS > anyway -- even if we could. (Because glibc's malloc implementation > doesn't do that unless we call that trim function, which we don't.) So > I'm not sure that makes much difference -- especially in a batch process. > > Does this mean that, once the heap size of the process has been increased by a large gc threshold, every subsequent gc will be proportional to the largest heap size ever required, regardless of whether some of it could be permanently freed? So, if the process terminates before collection, then it will run faster, but if it keeps running, the gc "pause" time will be permanently longer for each subsequent gc? --00000000000035a62605e1e06fda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 18, 2022 at 8:52 AM Lars Inge= brigtsen <larsi@gnus.org> wrote= :
Stefan Monnier <monnier@iro.umontreal.ca> writes:

As far as I know, we never actually release back cons space to the OS anyway -- even if we could.=C2=A0 (Because glibc's malloc implementatio= n
doesn't do that unless we call that trim function, which we don't.)= =C2=A0 So
I'm not sure that makes much difference -- especially in a batch proces= s.

=C2=A0
Does this mean that, once the = heap size of the process has been increased
by a large gc thresho= ld, every subsequent gc will be proportional to the=C2=A0
largest= heap size ever required, regardless of whether some of it could be=C2=A0
permanently freed?=C2=A0 So, if the process terminates before coll= ection, then
it will run faster, but if it keeps running, the gc = "pause" time will be permanently
longer for each subseq= uent gc?
=C2=A0
--00000000000035a62605e1e06fda--