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 17:55:00 +0200 Message-ID: <83inr7zjjf.fsf@gnu.org> References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <805F5A19-BFAF-4CA4-AAD6-497C6D554830@raeburn.org> <6e5c928f-8130-08a6-d72d-1b64cc022846@cs.ucla.edu> <1CB11DFF-E6C2-4A1B-BE7E-8877DC38DB0A@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1480348771 28959 195.159.176.226 (28 Nov 2016 15:59:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 15:59:31 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 16:59:25 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 1cBOKy-0006MP-8c for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 16:59:24 +0100 Original-Received: from localhost ([::1]:59623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBOL1-0004tW-US for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 10:59:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBOGm-00028e-JH for emacs-devel@gnu.org; Mon, 28 Nov 2016 10:55:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBOGj-0000d9-HK for emacs-devel@gnu.org; Mon, 28 Nov 2016 10:55:04 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBOGj-0000d1-ER; Mon, 28 Nov 2016 10:55:01 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2903 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBOGi-0007nH-Mb; Mon, 28 Nov 2016 10:55:01 -0500 In-reply-to: <1CB11DFF-E6C2-4A1B-BE7E-8877DC38DB0A@raeburn.org> (message from Ken Raeburn on Mon, 28 Nov 2016 04:36:56 -0500) 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:209650 Archived-At: > From: Ken Raeburn > Date: Mon, 28 Nov 2016 04:36:56 -0500 > Cc: Stefan Monnier , emacs-devel@gnu.org > > But we do use interior pointers sometimes; looking at Fsubstring’s handling of a vector object: > > else > res = Fvector (ito - ifrom, aref_addr (string, ifrom)); > > return res; > } > > … here we pass Fvector a pointer to somewhere within the “contents” array of the vector passed as argument “string”; it’s neither the Lisp_Object value, nor the start of the allocated structure. Now, I don’t think this is a case that can trigger GC at the critical time. But clearly we’ve got at least one case where we keep an interior pointer and — locally, at least; the caller could be another matter — don’t keep a live handle on the object itself. But 'string' still references the contents array of the vector, so GC will mark it when it comes to 'string'. > And the compiler can do it too. For example, if we did something like this: > > DEFUN (“frob-array-elts", Ffrob_array_elts, Sfrob_array_elts, 1, 1, 0, > doc: /* Blah */ ) > (Lisp_Object obj) > { > int i; > for (i = 0; i < 30; i += 3) > { > frob (AREF (obj, i)); > } > return Qnil; > } > > I tried compiling this (“gcc version 4.9.2 (Debian 4.9.2-10)” on x86-64). The generated code computes obj+3 (vector tag is 5, contents array starts at offset 8) and obj+0xf3 (end of the iteration), and overwrites the register containing the original “obj” value with the argument to be passed to “frob”. > > If, in this case, “frob” were something that could trigger GC, then stack scanning would not see “obj”, at least not in this stack frame. And if the caller is doing something like: > > Ffrob_array_elts (get_vector_of_stuff ()); > > then the caller needn’t retain any other references to “obj” either. Again, 'obj' will be somewhere on the stack up the call frames. Otherwise, how did it wind up in your frob-array-elts function?