From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Let's make the GC safe and iterative Date: Thu, 01 Mar 2018 18:38:45 -0500 Message-ID: References: <87inaiss6l.fsf@web.de> <6FCF6ACA-4F29-4B6B-BE9D-D7130C6E9495@gnu.org> <87fu5moe4c.fsf@web.de> <877eqyocro.fsf@web.de> <83zi3uz4nb.fsf@gnu.org> <0b1dd3fa-e0b0-ed20-a256-dd92d1c1826f@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1519947427 26341 195.159.176.226 (1 Mar 2018 23:37:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2018 23:37:07 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 02 00:37:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erXl0-0006Fy-2K for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2018 00:37:02 +0100 Original-Received: from localhost ([::1]:59772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erXn2-0000Kv-FP for ged-emacs-devel@m.gmane.org; Thu, 01 Mar 2018 18:39:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erXmw-0000Kp-GO for emacs-devel@gnu.org; Thu, 01 Mar 2018 18:39:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erXmr-0003Mu-KC for emacs-devel@gnu.org; Thu, 01 Mar 2018 18:39:02 -0500 Original-Received: from [195.159.176.226] (port=45555 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1erXmr-0003M6-Ck for emacs-devel@gnu.org; Thu, 01 Mar 2018 18:38:57 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1erXkl-0004pU-Hn for emacs-devel@gnu.org; Fri, 02 Mar 2018 00:36:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 23 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Re8z7r1boLfHfE9mO1I7+Ed/Bbw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223204 Archived-At: > We need to fix GC being deeply recursive once and for all. Tweaking stack > sizes on various platforms and trying to spot-fix GC for the occasional > deeply recursive structure is annoying. Here's my proposal: I'm OK with making the GC loop without recursing on the C stack, but I have two comments: 1- Don't use a queue: use a stack. Mark&sweep naturally work with a stack whereas stop© naturally works with a queue, so in most cases the choice is implicit/accidental, but experience shows that if we can choose, the stack is the better option (e.g. there's been various works that try to tweak stop© to use a stack rather than a queue), for reasons of locality. 2- Why do you say "We can't allocate memory to hold the queue during GC"? We very well can, and doing it should make things simpler (and make sure we don't preallocate way too much memory). If instead of a queue we use a stack and we just push Lisp_Object values onto that stack, the resulting space use can't be worse than what we have now (it's just going to use our malloc-managed stack instead of the C stack). Stefan