From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Concurrent GC via `fork` (was: Opportunistic GC) Date: Mon, 08 Mar 2021 11:03:48 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17555"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: eliz@gnu.org, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 08 17:05:05 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 1lJINU-0004R2-Uj for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 17:05:04 +0100 Original-Received: from localhost ([::1]:37386 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJINT-0003iW-U5 for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 11:05:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJIMO-000391-1P for emacs-devel@gnu.org; Mon, 08 Mar 2021 11:03:56 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36992) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJIMK-0001Wg-Pi; Mon, 08 Mar 2021 11:03:54 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D0D41809C7; Mon, 8 Mar 2021 11:03:50 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 330AF80159; Mon, 8 Mar 2021 11:03:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615219429; bh=zkgv6xz92TlCUdij5gkDAa4/tRFqT9KY6u/cY91j6M4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ollHJbIrMMSgTdqJvLw+0U9jRPq6RK47eVatCwpFA/pJy82yzx4o83Q+tLSjYbhj5 VjOiVkvGIpJtjwfZHDpxZoqyP68trWTTWHHP/J+R3O4Jf6SJlF45aywsfsGy80/9gr lsp1/DJ6ROwdpSDqzx3r0uG3ZgHDP4rX8jlcMQD1KVcbFw8SZB/nflNaRAgc8tGNjT +2pnni1c088qKKmpB8Onx2FGsfDIlMA7TMbqdkaxYrrgi2ppplZK2Z09H0ZS+UsVWG 3PSN4OGOuiuUST4vYAehFvjiVxbGpgnhK2vxSNauV443C4uiR1pQpnH10S41N9xrMK JfOr/SvZzfl0A== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CE94212014D; Mon, 8 Mar 2021 11:03:48 -0500 (EST) In-Reply-To: (Pip Cet's message of "Mon, 8 Mar 2021 07:20:28 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:266200 Archived-At: > Just a random idea: What if we exploit the fact most people have more > than one CPU core these days, garbage-collect in a separate fork()ed > process, then do only the sweeping in the main process? Sounds like a good idea. A concurrent GC which relies on `fork` to take the snapshot. I don't think we'll be able to always use it, so the synchronous code path will have to stay, but I think it's definitely worth working on it. It will probably require moving the markbits out of the objects in order to work well (which would probably be beneficial in the synchronous GC case as well), but other than that I'd expect it should be possible to get pretty good performance out of it in the "normal" case: - most pages should stay shared between the two processes (because the GC process should basically only modify its stack and its markbit pages, and the parent process should hopefully not have enough time to modify a large fraction of its working set). - the "normal" case I envision is one where there's a fair bit of extra RAM left in the system and a few CPU cores waiting to help Emacs. > Eli, would this qualify as a "small" GC change, and thus be vetoed? I like the idea, but its inclusion can't be discussed without a proof-of-concept patch. Stefan