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 14:33: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 1480361605 3102 195.159.176.226 (28 Nov 2016 19:33:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 19:33:25 +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 20:33:22 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 1cBRg1-0000Ch-S4 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 20:33:21 +0100 Original-Received: from localhost ([::1]:60755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRg5-0002k2-IE for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 14:33:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRfy-0002jt-DY for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:33:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBRfv-0001gr-5G for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:33:18 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11901) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBRfu-0001gY-Vr for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:33:15 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DdBQALW9BX/9qixEVdGwEBAQMBAQGDLQEBAQEBHoRNhVCvdoIDhhYEAgKBaTsSAQIBAQEBAQEBXieEYgEBAwFWIwULCw4mEhQYDSQsiCkIvFUBAQEHAiWKfYocBYYTiQqKPIwfhQyHYjGFWo8NgT4lCCeEbh6GCgEBAQ X-IPAS-Result: A0DdBQALW9BX/9qixEVdGwEBAQMBAQGDLQEBAQEBHoRNhVCvdoIDhhYEAgKBaTsSAQIBAQEBAQEBXieEYgEBAwFWIwULCw4mEhQYDSQsiCkIvFUBAQEHAiWKfYocBYYTiQqKPIwfhQyHYjGFWo8NgT4lCCeEbh6GCgEBAQ X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="280866324" 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 14:33:13 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 34F2762359; Mon, 28 Nov 2016 14:33:13 -0500 (EST) In-Reply-To: (Daniel Colascione's message of "Mon, 28 Nov 2016 11:18:32 -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:209674 Archived-At: > It's not just strings and buffers and intervals. The case of intervals is different because pointers to them from the stack aren't recognized by our conservative stack scanner (CSS), so they're more at risk, regardless of funny compiler shenanigans. > What about cons cells? There's nothing wrong with getting a cons from > something, doing something that might GC with its car, then doing > something that might GC with its cdr. There's nothing stopping the > compiler from keeping a pointer to the cdr instead of the car and > indexing when it's time to dereference the cons and get the cdr out > of it. Read Boehm&Chase's article: indeed, it's legal for compilers to do that. But Emacs is not the only program using CSS, so there is some amount of pressure to try and make sure C compilers don't make life impossible for CSS. > Let me ask again: we already have all the runtime data we need for more > conservative GC. Where is the resistance to the idea coming from? A few reasons I can think of for this inertia: - The problem is hypothetical. - Even if you pay attention to internal pointers, there are still (hypothetical) cases that won't be caught. - Noone volunteered to write it. - It will likely increase the CPU cost of stack scanning. - It will likely increase the amount of garbage we erroneously keep alive. Stefan