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: Wed, 10 Mar 2021 20:21:16 +0000 Message-ID: References: <83a6rdso07.fsf@gnu.org> <83a6rcqy4v.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="20314"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 10 21:23:08 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 1lK5MJ-0005C6-Mx for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Mar 2021 21:23:07 +0100 Original-Received: from localhost ([::1]:44820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lK5MI-0004VN-Le for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Mar 2021 15:23:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lK5LD-00040c-L8 for emacs-devel@gnu.org; Wed, 10 Mar 2021 15:21:59 -0500 Original-Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:35920) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lK5L9-0003Gn-Ks; Wed, 10 Mar 2021 15:21:59 -0500 Original-Received: by mail-ot1-x32e.google.com with SMTP id t16so17696056ott.3; Wed, 10 Mar 2021 12:21:53 -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=KHHc5eChrIr/13CmKBpsi6J6JBn+VkCSBXr6gwV+gEY=; b=uY/0Wia61cW72LQDjw+vmu7XXsT/nH1fukfQG2xbDWEnQ7xZfSlwnsN2PmUCNpIhaI zZ8lI4g/r3B+m4KOJkO5nrgoBm+L+1XDxWwrcULe4oCWfMaixGbUU3KL7A0Es/zICfnH /Ts02CWumdw4O+8w+4NBqcSOw6w9bTEW6NsdG/d/PVLiIpxAY+rkKfa4ztRsqXWj7j1e fTwtdT7WTdwAP5fZMK3cWCLnVb4j0skt4xibkfvGd1xPNiEGvWICpTK9LQwsokAx8T2B Gq0b5XkE8CPZ6KYUmhFQMKAbjWGfvOBPc2Uzj6eM3dDwIjbmurEb6p1sQbn7KLUN8DPJ oYSQ== 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=KHHc5eChrIr/13CmKBpsi6J6JBn+VkCSBXr6gwV+gEY=; b=OFcK9ZRWeQKjkuSIbjpbooTZPgLDYp+EdDgHN1sYHYKoZW9K6p27fIRo+6RhKei6b1 5vc1aUMb7Vm5JkU43NS8mImV28ZWfDXc0yNcDNdtbDIFHKskuAUWsKgA7mnuHmQdkzPH alYZDagrsB0EIqwBtV+ej7Q3kLv4vWAAbA/tRHy2RFArB0TuL7+ZcEDptuZcR+rVKzrm pluhhdbvaek/jFa2el+S6VFf83TNFRWSe9Br8a6ps0kfqp65vIV2nNpvzz9CmD1Xa/2D DmktAMJGCek4VvCUZyNfB8TXKlyUv6fUQ2H4mWnDrEJ02OAIGub3YsOgKUcNyt55+jWP PkfQ== X-Gm-Message-State: AOAM532D9miB44+udIBbpagrBsp8rOvnu9PrTlWHveibc9qCzRCd1/WN WDc5Xim8B/0CSAIL2mQOouFNl6cunxZhV/uYV5KoaydOOso= X-Google-Smtp-Source: ABdhPJxGxciwsw4gDbzas7OH9QLGT2B5NwZ29zHqOMB2bSOr9zUfW+CVEsYvrL0j40fCtz6pV6X5I01VGVFTrD/AIQ4= X-Received: by 2002:a9d:6e8d:: with SMTP id a13mr3897074otr.287.1615407713060; Wed, 10 Mar 2021 12:21:53 -0800 (PST) In-Reply-To: <83a6rcqy4v.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::32e; envelope-from=pipcet@gmail.com; helo=mail-ot1-x32e.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:266301 Archived-At: On Tue, Mar 9, 2021 at 1:01 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 8 Mar 2021 14:57:06 +0000 > > Cc: Stefan Monnier , emacs-devel@gnu.org > > > > > What happens when, on a 8GB machine, we have an Emacs session with a > > > 5GB memory footprint, and you fork and start marking (which triggers > > > copy-on-write)? > > > > That is, indeed, one of the cases in which we have to use the > > synchronous GC or suffer the consequences. > > How do we know if/when we are in that case? Because if we err, we > have a meeting with the OOM killer and a swift death. Yes, but there's a good chance we would have had that anyway, since it's "only" a factor of two, at most. I see similarities to how we decide how many processes to use for native compilation. The current rule in that case is "half the system's reported number of CPUs", however that is determined. I don't see why we can't do the same thing for memory: if there's a chance the GC process plus the current Emacs process exceed half of the lowest of 1. system memory 2. ulimit memory 3. a sensible upper limit, we use synchronous GC by default. Of course this should be customizable because users know best. If you're arguing that there is a strong case that synchronous GC should remain the default, I'm inclined to agree, because we haven't even tried the other way or gained any experience with it so far. But that does not mean it has no application whatsoever. I would gladly trade doubled memory consumption for reliable, reliably interruptible, zero-latency GC, particularly if it means never having to mask out mark bits before inspecting objects after a crash again :-) > > > Also, I quite frequently need to run Emacs on a system where I'm > > > forbidden to run more than 2 processes simultaneously ("make -j3" > > > aborts with an error message), and you propose to take those two > > > processes with 2 copies of Emacs? > > > > That is, indeed, one of the cases in which we have to use synchronous GC. > > Again, how do we know we are in that case? I assume you don't have a reliable getrlimit that lets you know? Pip