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 16:11:26 +0000 Message-ID: References: <666da624-2f59-2eb4-8e56-f0ad20dd900c@gmx.at> <26ff7447-9c29-a2f2-bf3d-9eac20a95d0f@gmx.at> <838s6xsnsv.fsf@gnu.org> 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="15549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 08 17:13:07 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 1lJIVG-0003uY-BK for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 17:13:06 +0100 Original-Received: from localhost ([::1]:47396 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJIVF-0000NU-2y for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 11:13:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJIUH-0008KW-O3 for emacs-devel@gnu.org; Mon, 08 Mar 2021 11:12:05 -0500 Original-Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]:35507) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJIUF-0005lJ-Qh; Mon, 08 Mar 2021 11:12:05 -0500 Original-Received: by mail-oi1-x233.google.com with SMTP id u6so4146772oic.2; Mon, 08 Mar 2021 08:12:02 -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=G0y+zAVXT1eaqoJGDvrHfJnfk/Rkqhks9Srilo6Fi5E=; b=p5XQ/RqC/i/x2nVDmZcvsxo2aaiwlAL/oOpIRTVmrHV2tmZ2bnLYy74D0yj9jRh+JM 2wRsaisZM0BMF8+DV7CSDZsDQTUt1+VpFH3L9duEIxnEWuqfL6w86iCFGPrJeRaolFMQ eKD1jEtvxMLk7/dd9xFVGiEnzLPB0cFwCvgj4csAXW8qRXYSGfxKMb3OjRF29gAz1v6e pLr7u2kMskFWzSUylRnUwXuyOGGyJ4Eqf9svBwVRB/2nDOpT3YrIbKSteDfO8Q3LQu9d zBsAx2c8hJCrTl1cEVLOXAz4mu0Ek1e+AEPMyzja8EHesK76O4ubZ2DWLYw24GKRUtn7 ITmA== 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=G0y+zAVXT1eaqoJGDvrHfJnfk/Rkqhks9Srilo6Fi5E=; b=snSTHmubldQOhZjTEKqgfXLaMTTbYliq46N1MXCWYxw4AkUTQiCfC0tB90uRA3NE8c 2YfHi9h6HdmmceGUWLQ1yMSKfbSV3Zci+HpAQmg0LaSYrwL8Xn2l13ipD2PbYSBLiox8 ik6M1jmSJ8NGGOvk3cqe25suAQ+37EpLpNRPRaFAMk//va9+tMDdxEYC+XqQgeqRekiu Ty3d9yvKzbtSWcfWWZsALPdcyUasXuMGpQbBfwud/emDPwzeziS6cOdyY7yEehESESyN +ayj9AE45zRxReHmkRnMbnczd6/ewmyGMJEU78a8ykwgFahhf5jcPGsYM0lQnao47u9a E0aA== X-Gm-Message-State: AOAM530f7knTcaa88AKfmA2rpqpKGaBgCMRKSSJBelljpYDswSstKmQB yHknwmaeZzS9cNUQItRGpmLM+kF93X2IDW3dMGg= X-Google-Smtp-Source: ABdhPJxT+flp/96jcrN6XFcPU6sPXsPaNNj4GGtX/X2EshuNTZHHpxpUj40JDiJhnnembD5W798aF5ZK2xF6fOqFCc8= X-Received: by 2002:aca:aad6:: with SMTP id t205mr17834048oie.122.1615219922229; Mon, 08 Mar 2021 08:12:02 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::233; envelope-from=pipcet@gmail.com; helo=mail-oi1-x233.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:266201 Archived-At: On Mon, Mar 8, 2021 at 3:46 PM Stefan Monnier wrote: > >> Ah, so not really an easy change after all. > > > > For conses, it's easy. Instead of keeping the mark bits in the cons > > block, we keep a pointer to the mark bits in the cons block, and > > allocate the mark bits separately and (hopefully) on a different page. > > What you mean is that it's easy because the markbits are already > separate from the cons objects (same for floats). We could also just > increase the size of the cons blocks such that their markbits area takes > up a whole page. That means cons blocks of about (* 16B/cons 8b/B) => > 128 pages => 512KB. I don't understand the benefits of doing that. The disadvantages would be very significant: we can't free a cons block until all its conses have been freed, and that's drastically more likely if we increase the cons block size by a factor of 128. Note that 4KB pages are no longer all there is. I hear even VAX uses a different page size ;-) > >> And how do you propose to keep the mark bits separately and still > >> maintain coherency between the object and its bits? > > Just as we do for pdumper, which already does this. In fact, I'm > > pretty sure it was Daniel who said a while ago that he wants to extend > > that to all GCable objects, not just those that live in the pdmp. > Yes, it's a good idea to do that in general. I agree it's a good idea to use the same approach for pdumped objects and regular old objects, but I don't think the current pdumper approach extends to dynamically-allocated objects, and I'd rather avoid searching a btree for each mark bit. That means pdumper has to be modified to keep its objects in blocks, and those blocks need a pointer to their mark bits, but we don't want to fault them in just to set the mark bits pointer, so we'd need a relative pointer, and then things start getting complicated... Pip