From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitrii Korobeinikov Newsgroups: gmane.emacs.devel Subject: Re: Garbage collector: is 800kb a good default? Date: Fri, 10 Apr 2020 22:26:19 +0600 Message-ID: References: <83o8s0on41.fsf@gnu.org> <83imi8oiyp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="1169"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 10 18:27:27 2020 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 1jMwV5-0000Dm-GV for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Apr 2020 18:27:27 +0200 Original-Received: from localhost ([::1]:36704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMwV4-00069V-JW for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Apr 2020 12:27:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36697) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMwUQ-0005Mf-OE for emacs-devel@gnu.org; Fri, 10 Apr 2020 12:26:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMwUP-0005oc-MH for emacs-devel@gnu.org; Fri, 10 Apr 2020 12:26:46 -0400 Original-Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:54415) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jMwUD-0005hp-44; Fri, 10 Apr 2020 12:26:33 -0400 Original-Received: by mail-wm1-x335.google.com with SMTP id h2so2951530wmb.4; Fri, 10 Apr 2020 09:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lrHCJeUx+CX7ilSBch/4KURPnxdrEb3n/M5wpp8sPlQ=; b=urXjQm07WCkCJldc5BOX3gBs2dxdR8y0FCcyNXJgIC8klyiRRYQvCP9H+zTPlJzy+q MW6QmhIpUX+w1fKqeUcAzIF6Hee8xbDyCH0dFFGgjVRQXP6Irsi4Cb/QZsm9hFxTTHce oz2nBtBgcvEMzVRnp/QP3c25ULlM/bz1IS2n4V1Tg+7u0ALdL9MC/5OpXr5LPEG+t4Rl tsx1L1i9jHfCNxUPv9G1lOeVVf4eQA7BgA31upUbNyhV8yRkiv5Iro7RT6VAf4w+9XzH zYCz23EfVqWVGyIsCsLfUg3fAQr7EVMK9omlPMZuWjzfCPrvaqOBM6HJ9UvoBJEgETgI vTdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lrHCJeUx+CX7ilSBch/4KURPnxdrEb3n/M5wpp8sPlQ=; b=MbARIomYGsUvkvi7sFX+AtbqKCM0QEvRDM1RojL53iexevUF2wVZXQJ6VQTxwygvni zUPVIrd53tZA1z7F4CPsn0+fNLyzBS34ecNYvuia+m4z/Eca9K6GcOZUjO0eQxHaiNbs oS1xwo6OTqMN0XZpoyy+8GOZgSJPij7Gnzh/De6LLsVLDnZFvshMWLmj42lpiJaymWzY bV7POgEXa4NdGr15hkq6sz5YIFC6ADdbZluWAvG9u+lyLg0rfndD6PtK44GWvN46qsKC fEI4lEoXvSfyjrPpt5XMRFRUIU6lqXIxO8UXUIvsXJ/jvOdFH+g2MNwelJsQTZjRsukj 2+3w== X-Gm-Message-State: AGi0PuZVNhDwR1YX/XQIJdNhDd/TfDH7EGfRZ0tvh/EvF2Vx1jTbkBX6 +iAy862AeQSFCRehpqGaZDkFYLr/LVoJ5VAnT40= X-Google-Smtp-Source: APiQypIBDGWrNPwzc011VCvHNLJKGcKuyGMnonWtWlgVhlQdVZ5LG9spEc8zXc+4z0NYlD8hSvrdVu6mNyqGZb0E/OQ= X-Received: by 2002:a1c:6503:: with SMTP id z3mr6088609wmb.92.1586535991265; Fri, 10 Apr 2020 09:26:31 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::335 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:246778 Archived-At: > It's called "incremental GC". XEmacs does it this way. That's cool, didn't know that! > to have, indeed. It's often not too hard to go from "incremental" to > "concurrent", tho, so I think if we want to go there we should aim for > a concurrent GC. I see. > I'm personally not too worried about that (I don't run much more than > Emacs on my machines), but a high GC threshold tends to lead to a large > heap indeed and the problem with it (for me) is that it tends to make > the GC yet slower (to which the naive reaction would be to increase the > threshold yet further to make GC even less frequent) and it can also > slow down the non-GC execution by increasing pressure on the memory > hierarchy (using more VM pages and more cache lines, reducing > effectiveness of the CPU's prefetcher) because the heap is more > sparsely populated. > > This is not documented with precise measurements, sadly. > So it's far from clear how much is too much. Thanks for expanding on these, I didn't know the details. For a start, I guess, just timing garbage-collect would work? Then what's left is to pick a few various ways to generate the garbage. Best, DK =D0=BF=D1=82, 10 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 01:05, Stefan Monn= ier : > > > Maybe it would be possible to garbage collect in chunks and check > > after each chunk for input? > > It's called "incremental GC". XEmacs does it this way. It'd be nice > to have, indeed. It's often not too hard to go from "incremental" to > "concurrent", tho, so I think if we want to go there we should aim for > a concurrent GC. > > > Stefan >