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 10:03:49 -0800 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> <838ts3zdpk.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 1480356273 7404 195.159.176.226 (28 Nov 2016 18:04:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 18:04:33 +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 19:04: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 1cBQHs-0000MU-PE for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 19:04:21 +0100 Original-Received: from localhost ([::1]:60427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBQHw-0000gj-LX for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 13:04:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBQHW-0000Vv-Vq for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:03:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBQHT-0003KR-0k for emacs-devel@gnu.org; Mon, 28 Nov 2016 13:03:59 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36048) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBQHS-0003K9-Jt; Mon, 28 Nov 2016 13:03:54 -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=LESHbZAMIOTzRZbje+2AVZ5QThvxJLcnV/Gzwzs6JX8=; b=qJD88dUGvWeNAuntjpOzsvw/fZ78XPnXmqBNCIRN7Dx1t0XqyhO1RKUEvqbIyM20mrzYTw45dO/qzEN+QvxVjMd7sALuaKEbPPabQvBk1iLwndK/AdDpIMfPuVXW5ys+UaZapWi1ts23Sh2MDBSbg3OpniHKZeD4WBikZmHsXDqkN/vom9H3jvQQVQjgTkQYaBJ8XEXxFEtsr37j5UkO4BRyxYdL74xFa4NN8bGDI4ILKRlQ3WUn/SLZRRYss0yOftDLu55i1Nn5rJyDK8Wk65I5OmZD0DqNhI0bcoXEmonLFL+mrZ3g5dKKxo72ubcph+RJ36zHsxJBN9iyWFXufw==; 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 1cBQHR-0006xi-9z; Mon, 28 Nov 2016 10:03:53 -0800 In-Reply-To: <838ts3zdpk.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:209662 Archived-At: 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? > 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?