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: Sat, 26 Nov 2016 17:12:36 +0200 Message-ID: <83poli1di3.fsf@gnu.org> References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480173206 5762 195.159.176.226 (26 Nov 2016 15:13:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2016 15:13:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 16:13: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 1cAefJ-0000cG-V6 for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 16:13:22 +0100 Original-Received: from localhost ([::1]:50885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAefN-0003a7-OT for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 10:13:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAeek-0003Zz-1L for emacs-devel@gnu.org; Sat, 26 Nov 2016 10:12:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAeeg-0007Fa-R6 for emacs-devel@gnu.org; Sat, 26 Nov 2016 10:12:46 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAeeg-0007FW-Nz; Sat, 26 Nov 2016 10:12:42 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4126 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cAeeg-00032E-1i; Sat, 26 Nov 2016 10:12:42 -0500 In-reply-to: (message from Stefan Monnier on Sat, 26 Nov 2016 10:03:39 -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:209618 Archived-At: > From: Stefan Monnier > Date: Sat, 26 Nov 2016 10:03:39 -0500 > > >> 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.) > > Indeed, this is a fairly delicate assumption that we don't check. > It's fairly rare to manipulate "struct interval" directly, so I think > the assumption is probably acceptable, but we should maybe document it > more prominently. Documentation aspects aside, if by "manipulate struct interval" you mean what we do in intervals.c between the call to make_interval and the return value being plugged into some Lisp object, either a buffer or a string, then we could set a variable during that time, which would cause an abort in GC, if that happens somehow. Would that address these concerns? If not, what kind of direct manipulations with intervals did you have in mind?