From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Mon, 28 Nov 2016 08:13:53 -0800 Organization: UCLA Computer Science Department Message-ID: <9a27456d-81a0-4692-0e0c-4a80ad9075b7@cs.ucla.edu> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1480349646 20913 195.159.176.226 (28 Nov 2016 16:14:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 16:14:06 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: Stefan Monnier , emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 17:14:03 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 1cBOZ7-0004p6-E2 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 17:14:01 +0100 Original-Received: from localhost ([::1]:59749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBOZB-0006ZJ-8R for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 11:14:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBOZ5-0006ZB-GS for emacs-devel@gnu.org; Mon, 28 Nov 2016 11:14:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBOZ2-0007YQ-BB for emacs-devel@gnu.org; Mon, 28 Nov 2016 11:13:59 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54886) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBOZ2-0007YH-4h for emacs-devel@gnu.org; Mon, 28 Nov 2016 11:13:56 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E7C49160065; Mon, 28 Nov 2016 08:13:54 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ArCyFydcKEUx; Mon, 28 Nov 2016 08:13:54 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 30029160066; Mon, 28 Nov 2016 08:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5GOYjp1FPt9X; Mon, 28 Nov 2016 08:13:54 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 17313160065; Mon, 28 Nov 2016 08:13:54 -0800 (PST) In-Reply-To: <1CB11DFF-E6C2-4A1B-BE7E-8877DC38DB0A@raeburn.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:209652 Archived-At: On 11/28/2016 01:36 AM, Ken Raeburn wrote: > here we pass Fvector a pointer to somewhere within the =E2=80=9Ccontent= s=E2=80=9D array of the vector passed as argument =E2=80=9Cstring=E2=80=9D Sure, but in practice there are always other copies of 'string' floating=20 around. Look at the call to Fsubstring in bytecode.c, for example: TOP =3D Fsubstring (TOP, v1, v2); There's another copy of 'string' in the stack. Even if that code were=20 changed to this: Lisp_Object v =3D POP; PUSH (Fsubstring (v, v1, v2)); Because the garbage collector doesn't know where the stack top is and so=20 scans the entire stack, the GC would still mark the string. In practice, Emacs C code doesn't create objects that no Elisp code=20 cares about, and then mess with those objects in a way that can cause GC=20 and that does not need the object base address. Partly this is due to=20 the longstanding tradition where such objects needed to be GCPRO'd=20 anyway. Partly it's because it's the Emacs C code is designed to be=20 subsidiary to the Lisp code, and it's unusual to create and mess with=20 objects not intended to be exported to Lisp. If Emacs code starts doing what you're worried about, then we'll have to=20 modify the GC marker to chase all pointers into objects, not merely base=20 pointers. But I don't see this being a problem in the current code.