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 20:50:30 +0200 Message-ID: <837f7nzbex.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> <838ts3zdpk.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480359060 19484 195.159.176.226 (28 Nov 2016 18:51:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 18:51:00 +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 19:50:56 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 1cBR0x-00046x-F5 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 19:50:55 +0100 Original-Received: from localhost ([::1]:60580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBR11-00044O-58 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 13:50:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBR0s-000448-Mw for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:50:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBR0p-000258-IC for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:50:50 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBR0p-000252-EL; Mon, 28 Nov 2016 13:50:47 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3651 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBR0m-0006lO-KK; Mon, 28 Nov 2016 13:50:47 -0500 In-reply-to: (message from Daniel Colascione on Mon, 28 Nov 2016 10:03:49 -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:209667 Archived-At: > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 28 Nov 2016 10:03:49 -0800 > > On 11/28/2016 10:00 AM, Eli Zaretskii wrote: > >> From: Daniel Colascione > >> Date: Mon, 28 Nov 2016 09:51:37 -0800 > >> > >> struct foo* f = something(); > >> int* x = f->&field; > >> something_else(); // invalidate global memory > >> *x = 5; // f is dead here, but still in scope > >> > >> Even if you don't write this kind of code, the compiler is allowed to > >> generate it. > > > > But there's no such code in Emacs, and will never be. > > I think you have too little faith in the ingenuity of compiler writers. > Why can't the compiler generate this sort of code in cases we don't > anticipate? Because no matter how ingenious the compiler writers are, they cannot produce code that will trigger GC where we didn't write such code to begin with. As long as there's no GC, the above is harmless. > > Lisp objects we > > create are either temporaries that can be GC'ed, or values that cannot > > be GC'ed, in which case they are passed to some other code, either a > > callee or returned as a value. The only ones that can be dead as > > above are the first variety, about which we don't care. > > When this assumption stops holding, it's going to be very difficult to > debug the resulting occasional crashes. Wouldn't it be easier to use the > information *already in the memory tree* to make GC more conservative > and understand interior pointers? I don't see why such assumptions should stop holding: we write code as part of the Lisp interpreter, not as just any C program. So creating Lisp objects just to fiddle with their C-side internals will never make sense, and code like that will always be rejected or rewritten.