From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Mon, 28 Nov 2016 22:03:18 +0200 Message-ID: <831sxvz81l.fsf@gnu.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480363427 5018 195.159.176.226 (28 Nov 2016 20:03:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 20:03:47 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 21:03:43 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 1cBS9M-0000Ku-E0 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 21:03:40 +0100 Original-Received: from localhost ([::1]:32781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBS9Q-0000CJ-7t for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 15:03:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBS9E-00009t-5E for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:03:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBS99-0004CV-UC for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:03:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBS99-0004CP-RX; Mon, 28 Nov 2016 15:03:27 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3775 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBS97-0004Gm-VP; Mon, 28 Nov 2016 15:03:27 -0500 In-reply-to: <97b09a32-c355-2f3f-2bff-1a3e1ef3b6be@dancol.org> (message from Daniel Colascione on Mon, 28 Nov 2016 11:40:22 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209681 Archived-At: > 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. > > 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).