From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GC and stack marking Date: Tue, 20 May 2014 09:44:05 -0400 Message-ID: References: <83a9add91p.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1400593476 6258 80.91.229.3 (20 May 2014 13:44:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 May 2014 13:44:36 +0000 (UTC) Cc: Fabrice Popineau , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 20 15:44:29 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WmkLD-00082I-Qu for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 15:44:27 +0200 Original-Received: from localhost ([::1]:53557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmkLD-0008OA-Fm for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 09:44:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmkL3-0008Ni-8H for emacs-devel@gnu.org; Tue, 20 May 2014 09:44:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmkKv-0000ty-O9 for emacs-devel@gnu.org; Tue, 20 May 2014 09:44:17 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:45669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmkKv-0000tp-JG; Tue, 20 May 2014 09:44:09 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4KDi6ke032225; Tue, 20 May 2014 09:44:06 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E530B60126; Tue, 20 May 2014 09:44:05 -0400 (EDT) In-Reply-To: <83a9add91p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 19 May 2014 19:31:46 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4948=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4948> : inlines <900> : streams <1188327> : uri <1762201> 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.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171947 Archived-At: > The short version of the question is: is it possible that a Lisp > object which is no longer referenced by anything won't be GC'ed > because it is marked by mark_stack due to some kind of coincidence? Yes, of course, it's what makes a conservative marking conservative. > So the huge hash-table gets dumped into the emacs executable, and That's bad luck, indeed. > causes all kinds of trouble in the dumped Emacs. But it shouldn't cause any trouble (other than extra memory use). > If this can legitimately happen, then how can we make sure this > hash-table indeed gets GC'd before we dump Emacs? First we should make sure that even if this table is not GC'd, Emacs behaves correctly. Otherwise, we probably have a bug that can appear in other situations. As for ensuring that the table gets' GC'd, there are 2 approaches: - provide a low-level "free-this-table" function which loadup.el could use. This is dangerous, since it basically says "trust me there are no other references to this object". Even implementing this function can be tricky; it would probably be easier to provide it as a C function only. - find where the spurious "reference" is coming from and add code to set this reference to some other value (e.g. it might be some variable left uninitialized, or a dead variable which we could explicitly set back to NULL or something), or to mark this memory location as "not a pointer" (like GCPRO but reversed: we'd do a NEGATIVE_GCPRO on the var (presumably of a type like int or float)). The Boehm's GC has developed ways to do this second option automatically: if during a GC, a memory cell is found to "point to" unallocated memory, then it is assumed to be of non-pointer type and this fact is recorded somewhere so that if in subsequent GC's this cell ends up "pointing" to allocated memory that won't be considered as an actual pointer. This can be very important when you get close to using the whole address space, in which case most addresses are allocated, so that many/most ints and floats end up spuriously pointing "somewhere". This doesn't work for us, tho, because we don't know when a stack location is reused for some other purpose (i.e. when it changes type), and more importantly because we have the Lisp_Object type which is a memory cell which can sometimes contain integers and sometimes pointers. OTOH, we are only conservative w.r.t stack scanning, so we're only subject to spurious pointers coming from the stack, not from the rest of the heap. And furthermore we have the great advantage that, as an interactive application, our stack regularly comes back to "almost empty" (and since we do "opportunistic GC" during idle time, we often GC at the very moment the stack is almost empty). Stefan