From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Mon, 28 Nov 2016 12:09:09 -0800 Message-ID: <508da2a6-15bc-ddf2-72b7-b1c35d9949c8@dancol.org> 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> <8337ibz984.fsf@gnu.org> <97b09a32-c355-2f3f-2bff-1a3e1ef3b6be@dancol.org> <831sxvz81l.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1480363782 1020 195.159.176.226 (28 Nov 2016 20:09:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 20:09:42 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 21:09:38 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 1cBSF5-0007Sq-QB for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 21:09:36 +0100 Original-Received: from localhost ([::1]:32811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSF9-00021Z-1O for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 15:09:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSEo-0001tR-8j for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:09:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBSEl-0006M1-30 for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:09:18 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:37554) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBSEk-0006KB-Le; Mon, 28 Nov 2016 15:09:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=jbLbPJWuUp2guZFsomMnaVkv0mdUeJrplcZlxotgy0I=; b=AbzSJ844a1mRP9V6+AI6iMs9MadSiucdYnPvJlR54lIjB5tlc76B0XTmZ4cBKBDQBTg5ARyTJIKJci2oqHys3hTI36VhzC98FQ+eDZftHQ2VGi0o+tiEEzpGjoIvBpuPp6z4GePCJuC9lKOFFc3Lzucn00Hb2RBrY01aR5IfROI08lyYkL7jkhqb64pO8wvuLHHFf+EJ0P2SXatlABApf+x9hyJlu/E0JxVoHD3J6xbgaG2O9KL2p242oRRr81Ftey7TYJ5veci77QatBt/LwbK3JqQr/B04Mzw/iYXfoka2bAJMzBLTF8dYbIEaHF9Dp0uUnOdH4oAztaTd6EaSyw==; Original-Received: from c-73-140-245-253.hsd1.wa.comcast.net ([73.140.245.253] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cBSEj-00086x-0X; Mon, 28 Nov 2016 12:09:13 -0800 In-Reply-To: <831sxvz81l.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209682 Archived-At: On 11/28/2016 12:03 PM, Eli Zaretskii wrote: >> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Mon, 28 Nov 2016 11:40:22 -0800 >> >>> I already answered that up-thread: it will be dead code, and thus will >>> likely do the wrong thing if it ever runs. >> >> We'll always have stray pointers to object interiors that will exercise >> these code paths. I've broken enough of them recently enough to know. > > We are not talking about broken code. It's easy to get yourself hung > in Emacs by writing bad code. Writing additions to GC to detect bad > code is not a good use of CPU cycles and of our time. What are you talking about? No matter how good the Emacs C code is, the compiler is legally allowed to generate code that trips up the current conservative GC. Code that looks perfectly safe may end up being compiled into something that trips up the current GC scheme. Even if it is possible to arrange C code such that, at runtime, we always keep GC roots around, the rules must be very subtle. We can make a simple, cheap modification to the GC to plug this hole once and for all. Other systems that use conservative GC have made similar modifications. I still don't understand why you're resisting this change when I've outlined a clear way in which things might go wrong. You're the one always talking about future-proofing the C core so that it needs less expert maintenance. This is a change that will future-proof the Emacs C core so that it needs less expert maintenance. >>> I also suggested what to do instead: add assertions that express what >>> we believe should never happen. Stefan says doing that is unlikely to >>> be justified by the dangers, but if we think so, then we shouldn't be >>> afraid of the problem in the first place. If we are, then adding >>> assertions is the way to go. >> >> It's not possible to assert, statically or dynamically, that we don't >> have this problem. > > If we cannot assert the invariants, either we don't really understand > the problem, or the problem doesn't exist in the first place (or > both). It's possible, from a CS perspective, to do a reachability analysis on the generated machine code and prove that all accessible objects have live head pointers. I think. But adding an analysis like this to the build process would be a research project in itself. It's easier to just make the GC more conservative.