From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Opportunistic GC Date: Mon, 8 Mar 2021 12:27:54 +0000 Message-ID: References: <666da624-2f59-2eb4-8e56-f0ad20dd900c@gmx.at> <26ff7447-9c29-a2f2-bf3d-9eac20a95d0f@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36744"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 08 14:18:51 2021 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 1lJFmd-0009Sh-FQ for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 14:18:51 +0100 Original-Received: from localhost ([::1]:33194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJFmc-0004MF-DB for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 08:18:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJEzz-0006qr-1x for emacs-devel@gnu.org; Mon, 08 Mar 2021 07:28:35 -0500 Original-Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]:38258) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJEzx-0000Zo-Bu; Mon, 08 Mar 2021 07:28:34 -0500 Original-Received: by mail-oi1-x231.google.com with SMTP id v192so3185484oia.5; Mon, 08 Mar 2021 04:28:32 -0800 (PST) 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; bh=VpKVWuyM3PQZD6JBzo2jxZ/zAzcE8AjCV+6I0OWZfbs=; b=eHLhXF+rQUNUUz/EgYimyD82vj0u7pJNQYedQvW4d9XKtyHFZyFE5By3YMMwldEjM9 4kGohFisXsNYee7vg90FfejPOV/2AltaGEvluaP22enHcFM0e+rLHia0+PJEXqFS/d9A A2peRCmL7do9mnW71IZ5O/GcfxFaWatcxtjtY2E5EMYaDAlG/xYTXFv5nXFAW8Nw/ghq +w+RVKLb6+mZTucf9t5MVD5qqinCKpHQtMvpMHTWXNclb2eR57V0xuSuItPZUESpq+Al ruxyEuoxWG3OEdBUydYTMQHG+0cJ2FcIY2wCMfzGE06sB1xLKgnMCg0DiqihzwHRX882 yWjg== 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; bh=VpKVWuyM3PQZD6JBzo2jxZ/zAzcE8AjCV+6I0OWZfbs=; b=FgJAcVtwfJQFXsJXGvaIDN0u+L8NH2iYbbayQNvESKpLVlsQSSxZ+60ZXavt5uhDxh 0VSXe4S/DIFpa1KMbKr6SYwKRU0mPI35AEp0mTaJV6m4hEE3dWdq7Lf5Y+i5bS06CqrF uogsUQPloKGPYz6S1ebZ8SbuMdKSoB25ISzgle1Uc8j137nh9QkU2Bp9EcO0badFB2qO VlfMN/mF/OamCPNNP+rv845elCkMBorDaCxXhsqKyVA4YNct0xSEHDff/JnR2JXdB75U CW13BPf8SfxrmVU4ImBZ38AHQog/UQCOEn2RuMnze5lbbLmZnofOjEK29ui3duLMo3KJ w45w== X-Gm-Message-State: AOAM530Rh4GLJCo8yribDaYV8ZQ3gkJIOqq1asBlekb1opRCzZ9Y3mnV 0hcOHgOpjLUi/UkwPzH0Fdqh1/coc0oPWYFbQss= X-Google-Smtp-Source: ABdhPJxWO6DlSSeQzrxzXd3vlZh0HX8faOZS/fgQVRdc+cKJLpCj4xjkJ9DjI39jtwQfzOemX1594Y/G5og0Ut2QhJ4= X-Received: by 2002:aca:4c0f:: with SMTP id z15mr13392862oia.44.1615206511911; Mon, 08 Mar 2021 04:28:31 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::231; envelope-from=pipcet@gmail.com; helo=mail-oi1-x231.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:266175 Archived-At: On Mon, Mar 8, 2021 at 11:37 AM martin rudalics wrote: > >> And short-lived objects have to > >> wait for the next cycle to get recovered. > > > > I'm not aware of any GC algorithm that recovers objects allocated > > after the GC cycle started :-) > > In the early phase of a collection cycle most objects are unmarked so it > would make sense to give a new object the mark status of the first > object referencing it. But that's admittedly hard to do with ambiguous > roots. Perhaps it's worth keeping in mind that this is a relatively simple change, not a complete GC rewrite. > > Mostly that there should not be a doubling of memory usage. With the > > mark bits fixed, memory usage would grow by, at most, 1/64th the heap > > size on 64-bit systems, plus a constant. I think we can live with a > > 1.5% increase in memory usage if we get (effectively) zero-cost (or > > zero latency) GC in exchange. (I'm assuming there'll be an unused CPU > > core, which is usually true for me (unless I'm compiling something)). > > With the mark bits not fixed, memory usage would increase by > > approximately the size of the surviving heap, but not the size of the > > discarded heap pages. > > But doesn't that depend on how many writes the Lisp thread performs in > the heap? You're right, it does. Thanks for correcting me on this point. I don't think it's going to matter in practice, though. GC, after all, does not take that long, and the retained working set of most Lisp programs is small, memory is cheap, and it is a factor of two in the absolute worst conceivable case. > Each such write causes its associated page getting written > out to avoid that an old link gets lost. And if the action was to drop > an old link, writing the page out doesn't even make sense. I'm not sure what you mean by "drop an old link". > > Note that none of this is "real" GC: we still mark and sweep, just in > > a slightly smarter way. > > If with "real" you meant "real-time", then it might qualify as such. No, I meant "real" as opposed to mark-and-sweep style algorithms. Generational would have been a better (but possibly slightly narrower?) term. Pip