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 11:18:32 -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> 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 1480360739 14101 195.159.176.226 (28 Nov 2016 19:18:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 19:18:59 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 20:18:54 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 1cBRS1-0002p2-4T for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 20:18:54 +0100 Original-Received: from localhost ([::1]:60685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRS4-0005Rt-I3 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 14:18:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRRr-0005Qc-9Q for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:18:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBRRn-0004xL-7h for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:18:43 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36982) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBRRm-0004ww-QZ for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:18:39 -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=01SB1/pGKJ+a/FsLoUAzg4DVUqPNZ9NBWUHDe/vzABc=; b=YdadjMHiwEVgHG9yOPE+G5Tz3+nmJwmUi5/PVf32CDyrCdimuDOgcb9btb917BIxlOeAaQmxCQAfnbdYPCEx/ani84Zd2gLqHUqSVGUIwib7ErLN6w5hv6hEBKCwXHsRkqnfCIb6rI1GPiOmVsz3r7jknzZCH/NLyNnysCmeodZ95XW4NfUY/3S/+/eoXAd5Gp+mLc3Ry4ghdBIr7pdfiYhHnGXe9wwCdhJ5VZbJx+ikAulEUx8vDJXjgsNakT6GxDG9ZvyLt/C9BOAKuMj6fvkTxy51w1z++mudrTLNeapCeEIVTfIrfjG5dMsTj2eUDZr/N1DbiK2k1onG2MI6sg==; 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 1cBRRj-0007eI-Tt; Mon, 28 Nov 2016 11:18:35 -0800 In-Reply-To: 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:209672 Archived-At: On 11/28/2016 10:03 AM, Stefan Monnier wrote: >>>> How would you assert dynamically that if an interval is reachable, its >>>> owning string or buffer must be too? >>> You don't. You check it statically (by a human). >>>> It's not enough for the variable holding the reference to the string >>>> or buffer to be in scope: you have to be sure that the reference >>>> isn't dead. >>> It should be: if it's in scope, it's not dead. >> That's not the case. > > In general, no, but in this specific case I think it always will. > E.g. because in order to be in the process of working on the intervals of > a buffer, that buffer needs to be not just reachable but buffer-live-p, > so you'd have to mess with buffer-alist before the buffer can be > reclaimed, which is highly unlikely to happen within the functions that > manipulate intervals. > > For strings, the argument might not be as strong. Maybe code like > (ignore (propertize "foo" 'a 'b)) could lead to us working on an > unreachable string, so it could get GC'd while we manipulate its > intervals. > > So for those cases, I guess the main safety argument we have is that we > will not call the GC while we're in the middle of manipulating struct > interval objects. It's not just strings and buffers and intervals. 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. It's legal for the compiler to emit code that does things like this. That it hasn't happened yet is no guarantee that it won't in the future. 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?