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: Re: Concurrent GC via `fork` Date: Mon, 08 Mar 2021 12:37:57 -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="1360"; 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 19:26:48 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 1lJKae-0000AD-Nv for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 19:26:48 +0100 Original-Received: from localhost ([::1]:45354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJKad-0001p6-OK for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 13:26:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJJpZ-0004zN-VN for emacs-devel@gnu.org; Mon, 08 Mar 2021 12:38:09 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11647) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJJpU-0000iN-F5; Mon, 08 Mar 2021 12:38:08 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9D12B80229; Mon, 8 Mar 2021 12:38:00 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 76DBE804E6; Mon, 8 Mar 2021 12:37:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615225078; bh=UsBaD/kVqtmSAmOCE8qiPOj4SgWYalMAkCL4G3Teabs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=B8AvJAzS7jTpRrMaCXFsplP/UQ4MM2kuEQhooXfG4iMPgm/LtEGEUwdPsLh4miLD8 5CnASiOlqTsqNrzOYteopZ2MT1GnOeC0WwXdxMWuEeq7Z5rFJe5aGFPRrAFP0tfobb dylYy1kLKeafBw05ZpVfwJmTGug81zJSt+8j2aH/jeL32r7VUoWwbqed5cm4shjprp zVe/70yvQhtakYBcRa/H+8LFH1TFbVIeRSmLFC8e9+IAOQLKo8l6zi4bvO9qJc3AlA jFDt3fon+p9/sSUwDmDK7fUXAPedkH3K5NfFodQErGAR4e1DI45AbyHF8DlU31iOjt 4Sx10DsQaNu7g== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 268E912030A; Mon, 8 Mar 2021 12:37:58 -0500 (EST) In-Reply-To: (Pip Cet's message of "Mon, 8 Mar 2021 16:25:57 +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:266214 Archived-At: > And I do want to mention weak hash tables: they're a problem, because > they can resurrect unreachable objects. Indeed, weak pointers require special attention to handle them correctly with concurrent GCs. But nothing insurmountable. > Worse, while normal weak-key-strong-value hash tables only resurrect > objects when you maphash, weak-value hash tables can do so for gethash > as well, so that code path would become more expensive I think it can be made "cheap enough". > and more difficult to translate into native code. I don't know what this has to do with native code. >> but I think it's definitely worth working on it. > I've got it working for conses, I think (as a proof of concept, > synchronously, with an extra waitpid()). I think a real proof of concept is one where the GC is never run synchronously. > Apart from hating threads and loving processes, I love nice levels, > and I think this would be a good use case for them. For example, I > hear there's a new CPU out there that has two separate sets of cores > for "efficiency" and "performance", and it would be great if Emacs ran > an "efficiency" garbage collection in the background rather than a > "performance" garbage collection synchronously. To the extent that the GC normally only uses less than 50% of the CPU time, indeed we don't need it to run as fast the main thread. More generally, the OS scheduling of the GC process should focus on maximizing throughput rather than minimizing latency. Stefan