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: Fri, 02 Mar 2018 08:47:31 -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 1519998346 18264 195.159.176.226 (2 Mar 2018 13:45:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Mar 2018 13:45:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 02 14:45:42 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 1erl0H-00042f-8F for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2018 14:45:41 +0100 Original-Received: from localhost ([::1]:35086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erl2J-0004FB-P4 for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2018 08:47:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erl2D-0004Eo-Lr for emacs-devel@gnu.org; Fri, 02 Mar 2018 08:47:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erl29-0007br-NN for emacs-devel@gnu.org; Fri, 02 Mar 2018 08:47:41 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:51118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erl29-0007be-H1 for emacs-devel@gnu.org; Fri, 02 Mar 2018 08:47:37 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w22DlVNF025811; Fri, 2 Mar 2018 08:47:32 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 8833E5FB8F; Fri, 2 Mar 2018 08:47:31 -0500 (EST) In-Reply-To: (Daniel Colascione's message of "Thu, 1 Mar 2018 16:05:42 -0800") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6234=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6234> : inlines <6446> : streams <1780450> : uri <2601940> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:223220 Archived-At: > Sure. Using a stack instead of a queue is a minor detail; the basic > algorithm is the same. The point is that a stack will be better locality-wise and (more importantly) that it should be as good as what we have now w.r.t memory use (actually, it should be significantly better, because at each "recursive" step we only push one Lisp_Object on our stack whereas the current code pushes an activation frame which is at least twice as large since it also needs a return address). So I think it does affect the algorithm: I'm not convinced we need to do anything special for objects allocated from blocks. >> 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). > We can try, but we need a plan if allocation fails. We can just abort the GC (only requires resetting the markbits). It's not like we GC when our memory is full: we just GC on a regular basis for "prophylactic" reasons. > I don't think the worst-case preallocation overhead is severe enough > that we have to give up malloc robustness. It sounds pretty significant to me. I could live with it if it were indispensable but I find it difficult to justify. > Sure, except that stack use is ephemeral, Our manually-managed stack can have the same property. > and the space we allocate for the stack gets used for lisp too. Yes, that's a downside of such a change w.r.t average use of the combined stack space, but I don't think it affect the maximal combined stack space, so I'm not worried. This said, we could also move the Lisp stack to that same manually-managed stack (at least for the bytecode stacks). Stefan