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 10:44:06 +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="27340"; 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 11:45:42 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 1lJDOP-00072d-Sb for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 11:45:41 +0100 Original-Received: from localhost ([::1]:41550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJDOO-0001zV-UN for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 05:45:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJDNY-0001NN-Fv for emacs-devel@gnu.org; Mon, 08 Mar 2021 05:44:48 -0500 Original-Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]:40719) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJDNV-00041k-RN; Mon, 08 Mar 2021 05:44:48 -0500 Original-Received: by mail-oi1-x22f.google.com with SMTP id w65so10468467oie.7; Mon, 08 Mar 2021 02:44:45 -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=9doR/bjyjwb1Zf1KnrkBuqGAqEolX2Zxc2zr77biOIo=; b=b3ZzgKwiKonTTxEuhKVrMzlOZH1VuSqRG4HNGDJCmDdsHzl05UY4M01S7PMVahXDTL AuyP8I9rntoiWzMdtUqspC3io7yZRo55HIo6SR/7Jz/uEZ64QupnTAQIH+IPxSOqBqzk 0eCxw9DFGtgKZfDPQxnpgJmsjhh5QHAUU0a3Vaq8zMJeS/QIC5n8CVa3LdkZ7zU/yubj 5R4gXzy+tJflfYmRw5RUXJfrgcSAZTg6+8D6FzyuhSZAyFxJwE437nWTT/U8hMFCLqAm oHVeBd4agAKTJFOwR1XaurNDvLW7WSRasx9dcZtNi1lbrRdbAnXVt6tEUjxfu1UgHwAo +Sgg== 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=9doR/bjyjwb1Zf1KnrkBuqGAqEolX2Zxc2zr77biOIo=; b=MGcmLw67wgJ540guhisxOIayaErgdWiJ3a/7pBsohthIbF3+CluZQdm9lFMUbnRN8u Ma/tXhKoUy3akklnupMZWkNYtERs0q5ZoC7p/p6XYXFLe3f/gMQq76qgXcXkW7TTzLHj 92xPimpn8EsbbKqHniMhlapoWsFNuvQ/E5O8YBgvfKTHfXVI9oFY/0dL66qhixxfkTSO 5QcnolIxCMjnm8bmP+rj7iQxBplE4qiX88rv1AGFqTSvwhDUhhuzMW3aT9ZlrMq0sc0d q5toh81aDlzcWSyHle5fo6wk9K6lWduZJjK2sTS5jqZi30kj40njX2dCHpkGj61QqpP8 4Wsw== X-Gm-Message-State: AOAM533o+NrWP4n8d8NK5JzDxDhP+vT98Wd/MTSSDxQDXSScw82g7iFp X3yDPAvmOBe/7RYSrERkJweuMj/vEOm3sPaVLco= X-Google-Smtp-Source: ABdhPJyWrkMijugUNyHya1ilV0VXbsvBHfq0drABXYY4FnLgea0fM3Kutaf96ZgigfI3jdJIsb2Yk9KPjCuitUUNwtQ= X-Received: by 2002:a54:4196:: with SMTP id 22mr6218862oiy.30.1615200284367; Mon, 08 Mar 2021 02:44:44 -0800 (PST) In-Reply-To: <26ff7447-9c29-a2f2-bf3d-9eac20a95d0f@gmx.at> Received-SPF: pass client-ip=2607:f8b0:4864:20::22f; envelope-from=pipcet@gmail.com; helo=mail-oi1-x22f.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:266169 Archived-At: On Mon, Mar 8, 2021 at 9:51 AM martin rudalics wrote: > > We fork(), we don't clone(). If A exists at the time of fork() but > > isn't reachable through the thread's stack, that's a bug anyway; if it > > doesn't exist yet at the time of fork(), it's not collected in this > > cycle. > > I have no idea what the difference between fork and clone implies here. fork() is a (relatively) cheap copy-on-write "copy" of the address space. clone() would cause severe problems, of the type you describe above. fork() is the (very, computers are expensive) poor man's way to avoid those problems. > IIUC you have to make a copy of Lisp thread and heap, have the collector A "copy", as above. > operate on the copies and, when done, pass the now unmarked objects to > the Lisp thread for recycling in the original heap. IIUC that doubles Yes, that part is correct. > the size needed for heap and stack. Not quite. It's a copy-on-write copy, and we would avoid unsharing the pages we don't set mark bits in. Pages that get collected don't have set mark bits, so they wouldn't get copied. And, yes, we should keep the mark bits separate from the data so we could avoid unsharing an entire page because a single object in it survives GC. If the stack is of significant size (it usually isn't), it won't get copied, either. > 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 :-) > Or what am I missing? 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. In addition to keeping the mark bits discontiguous from the marked object, we should free entire pages without, as we do at present, first faulting them in. That's part of the reason Emacs does so badly when the system starts swapping. Note that none of this is "real" GC: we still mark and sweep, just in a slightly smarter way. Pip