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: Conservative GC isn't safe Date: Mon, 28 Nov 2016 13:03:13 -0500 Message-ID: References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <69a1fdf3-7120-125b-8556-d74f5afc6b37@dancol.org> <8360na399k.fsf@gnu.org> <26a81224-c61e-27ac-37b4-5e7bd1e90910@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480356234 20294 195.159.176.226 (28 Nov 2016 18:03:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 18:03:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.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 Mon Nov 28 19:03:48 2016 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 1cBQHL-0004Vs-9Z for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 19:03:47 +0100 Original-Received: from localhost ([::1]:60424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBQHP-0000LS-37 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 13:03:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBQGs-00005D-1z for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:03:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBQGo-0003Aq-VI for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:03:18 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:2171) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBQGo-0003Ai-PI for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:03:14 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DeBQALW9BX/9qixEVdGwEBAQMBAQGDLQEBAQEBHoRNhVCxeYYWBAICgWk8EQECAQEBAQEBAV4nhGIBAQMBViMQCw4mEhQYDSSIVQi8VQEBAQcCJYp9ihwFjx2KPIkkj2mGC48NgT40IIRuHoYKAQEB X-IPAS-Result: A0DeBQALW9BX/9qixEVdGwEBAQMBAQGDLQEBAQEBHoRNhVCxeYYWBAICgWk8EQECAQEBAQEBAV4nhGIBAQMBViMQCw4mEhQYDSSIVQi8VQEBAQcCJYp9ihwFjx2KPIkkj2mGC48NgT40IIRuHoYKAQEB X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="280858310" Original-Received: from 69-196-162-218.dsl.teksavvy.com (HELO pastel.home) ([69.196.162.218]) by smtp.teksavvy.com with ESMTP; 28 Nov 2016 13:03:14 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9E87162359; Mon, 28 Nov 2016 13:03:13 -0500 (EST) In-Reply-To: <26a81224-c61e-27ac-37b4-5e7bd1e90910@dancol.org> (Daniel Colascione's message of "Mon, 28 Nov 2016 09:51:37 -0800") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:209661 Archived-At: >>> How would you assert dynamically that if an interval is reachable, its >>> owning string or buffer must be too? >> You don't. You check it statically (by a human). >>> It's not enough for the variable holding the reference to the string >>> or buffer to be in scope: you have to be sure that the reference >>> isn't dead. >> It should be: if it's in scope, it's not dead. > That's not the case. In general, no, but in this specific case I think it always will. E.g. because in order to be in the process of working on the intervals of a buffer, that buffer needs to be not just reachable but buffer-live-p, so you'd have to mess with buffer-alist before the buffer can be reclaimed, which is highly unlikely to happen within the functions that manipulate intervals. For strings, the argument might not be as strong. Maybe code like (ignore (propertize "foo" 'a 'b)) could lead to us working on an unreachable string, so it could get GC'd while we manipulate its intervals. So for those cases, I guess the main safety argument we have is that we will not call the GC while we're in the middle of manipulating struct interval objects. Stefan