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: Sat, 26 Nov 2016 00:33:13 -0800 Message-ID: <69a1fdf3-7120-125b-8556-d74f5afc6b37@dancol.org> References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> 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 1480149205 6426 195.159.176.226 (26 Nov 2016 08:33:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2016 08:33:25 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: Paul Eggert , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 09:33:21 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 1cAYQD-0000i8-2n for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 09:33:21 +0100 Original-Received: from localhost ([::1]:49652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAYQG-0008I2-Gj for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 03:33:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAYQ8-0008Hw-JZ for emacs-devel@gnu.org; Sat, 26 Nov 2016 03:33:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAYQ7-0002cw-OC for emacs-devel@gnu.org; Sat, 26 Nov 2016 03:33:16 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50102) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cAYQ7-0002ch-AI for emacs-devel@gnu.org; Sat, 26 Nov 2016 03:33: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:References:To:Subject; bh=wST/EZJVsGHtAZmnuEvfPxYXxVeuw1LWrtQqma5yaa8=; b=XQgrk1OpfZJkFWpqwcVyPeTdhMsASJPX/E0m4IRFLa9NRqhnXVm01g1nlD9lHtGZMaO7u3Wj9RtQoK17O1gY3j6aj8vd0GTm6NGIVYDHeAx5fMxajzl/xqtEOwx7sgjHgOCWrZ80wrT3rrX0oJMV6oRMRoZInlzgpRNJZEMYmq2ITwnnzpQd5GM7l4w5jGVxiAk6NXrk5DJTz76Dtty5FYZ8B96fPgdmsImdaDDAO2nALMNGRiyK4rTs6pmclMIvRbTqxAyMdnNzwmjoa4XIphJi08+rsnbFNf94fycsNQJbY4xothQ1M2ZLHlfJhOUApwi/NLh87Ve45MwqxvkQZw==; Original-Received: from [2601:602:9802:d9d1::350] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cAYQ6-00021h-8U; Sat, 26 Nov 2016 00:33:14 -0800 In-Reply-To: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> 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:209607 Archived-At: On 11/26/2016 12:30 AM, Paul Eggert wrote: > On 11/26/2016 12:11 AM, Daniel Colascione wrote: >> >> 1) mark_maybe_pointer looks only for exact matches on object start. >> It's perfectly legal for the compiler to keep an interior object >> pointer and discard the pointer to the object start. > > Yes, just as it's perfectly legal for the compiler to subtract 42 from > every pointer before putting it in a register or storing it into memory. > In practice, though, compilers don't do this around calls to the garbage > collector. (True, this assumption should be documented better.) I can imagine a compiler having a legitimate reason to use an interior pointer, but I can't see why it'd subtract 42, XOR it with 0xDEADBEEF, or make other opaque transformations. We already search the memory tree, and each tree node has both start and end information for each allocation. We should be able to cope with interior pointers. >> 2) INTERVAL is GCed, but it's not represented in the memory tree: >> struct interval isn't a real lisp object and it's allocated as >> MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval >> won't protect it from GC. Shouldn't we treat intervals like conses? > > Does the code ever create an interval that is accessible only via locals > when a GC occurs? If not, Emacs should be OK. (This should also be > documented better.) Anywhere in the code? Forever? I wouldn't be confident saying so.