From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#17168: 24.3.50; Segfault at mark_object Date: Sun, 06 Apr 2014 13:13:39 -0700 Message-ID: <5341B573.1010605@dancol.org> References: <87y4zop44m.fsf@yahoo.fr> <533C3AF5.6070502@yandex.ru> <533C6905.9060309@dancol.org> <83bnwjbh8v.fsf@gnu.org> <533C75A6.60900@dancol.org> <533D06E6.2060001@yandex.ru> <533D07EF.1040502@yandex.ru> <533D13E2.3060300@dancol.org> <533D251E.3030108@dancol.org> <533D6A19.8050504@yandex.ru> <533D9099.3000104@dancol.org> <533D9F2C.7030500@yandex.ru> <533D9FBB.2050803@dancol.org> <533DB4F0.20706@dancol.org> <534085B1.9070307@dancol.org> <534176F3.9090205@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB" X-Trace: ger.gmane.org 1396815265 21878 80.91.229.3 (6 Apr 2014 20:14:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Apr 2014 20:14:25 +0000 (UTC) Cc: Dmitry Antipov , 17168@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 06 22:14:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WWtSL-00065H-PZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Apr 2014 22:14:18 +0200 Original-Received: from localhost ([::1]:59160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWtSL-0001AM-B2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Apr 2014 16:14:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWtSC-0001A6-Gj for bug-gnu-emacs@gnu.org; Sun, 06 Apr 2014 16:14:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWtS6-0004mb-PK for bug-gnu-emacs@gnu.org; Sun, 06 Apr 2014 16:14:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWtS6-0004mV-Hn for bug-gnu-emacs@gnu.org; Sun, 06 Apr 2014 16:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WWtS6-0004YZ-8M for bug-gnu-emacs@gnu.org; Sun, 06 Apr 2014 16:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Apr 2014 20:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17168 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 17168-submit@debbugs.gnu.org id=B17168.139681522617479 (code B ref 17168); Sun, 06 Apr 2014 20:14:02 +0000 Original-Received: (at 17168) by debbugs.gnu.org; 6 Apr 2014 20:13:46 +0000 Original-Received: from localhost ([127.0.0.1]:38401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtRp-0004Xr-Ne for submit@debbugs.gnu.org; Sun, 06 Apr 2014 16:13:46 -0400 Original-Received: from dancol.org ([96.126.100.184]:46195) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WWtRn-0004Xh-19 for 17168@debbugs.gnu.org; Sun, 06 Apr 2014 16:13:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uFdGg0yHI2dp7LNaP5uTfdYjSYjVi1+/GtCqXs5f2AU=; b=XgiTG3B9Rvxb2+XfsQjIs6dGmbf3jmt2YlqblE4f+BYZoiDef7jCY1/21qwdrOzLMae93o2NxdITAAnUn9WeHNsSreQCNLRQqUTyVGdKRXuc56/eGbgDaw/jZ/PaxnvLlZ/wpg4uZLFeN1EbtiyV5LaRvUs3BDcfTeeOXl89vKxLob6octKOhizMvjL7JlOIydo2mlGvC6iNntPBX2w0zKaN1OURsGhU5WX8JstIBA45h1s8NS0M3oU6wojoaUOK2GCHkL2mdOhlqKx324RD338zOfGWFZ18Bu1mvr+JLK4IDppU3pXu783vMw0sgiQNO0vnZ4daSFgC+OLOajAhJA==; Original-Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WWtRk-0006NS-Gu; Sun, 06 Apr 2014 13:13:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: X-Enigmail-Version: 1.6 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:87830 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2014 12:58 PM, Stefan Monnier wrote: >> The pinned bit approach is exactly what I implemented, except that we >> walk obarray, like we already do, instead of all symbols. >=20 > We already walk obarray during the mark phase, so I don't understand > what you mean here. I meant that, IIUC, you mean to "pin" symbols by adding a pinned bit to Lisp_Symbol, then at sweep time, enumerating all symbols in all symbol blocks and marking those with this bit set. My approach is similar, except that instead of an explicit mark pass over the symbols, my patch just relies on obarray to keep these symbols alive, then forbids removing these symbols from obarray. This way, the existing walk over obarray does the job of the all-symbols walk we'd need otherwise. >> Your approach would require that we check for non-symbols in purecopy >> and reject them, >=20 > Yes. Well, we already do that for markers. Still, I don't like making general mechanisms less general. >> and it'd have a bigger performance impact, since we'd >> then need to walk the entire symbol list essentially twice. >=20 > Indeed. I don't expect it to be significant, tho. As you point out we= > already walk that list once during gc_sweep, so doing it one more time > should be very quick. =20 Maybe. We might have tens of thousands of symbols. We don't GC that often, sure, but the overhead isn't nothing. On the other hand, if we're walking all symbols during marking, we can avoid walking the initial obarray, since we already know which symbols are interned there from the Lisp_Symbol interned field. (We can't use the same approach for other obarrays because we want them to eventually get GCed even if they have interned symbols.) This approach still gives up generality and doesn't do much about the complexity, but it does save us 350 words of pure storage. > Also, I'd expect that a significant proportion of > all symbols would be marked with that bit, so scanning all symbols won'= t > take that much longer than the alternative of only scanning a vector of= > pinned symbols. Also scanning all symbols like gc_sweep means that the= > scan is nicely sequential in memory. >=20 >> I'd strongly prefer the fully general approach in my patch. It isn't >> *that* complicated. >=20 > But it requires more memory, ~350 machine words, all in pure storage. > whereas we already have space for an extra > bit in the Lisp_Symbol struct. I guess the main difference resides in > whether we want to allow uninterning pinned symbols. If we do as you > suggest and disallow it, then indeed, I expect there to be rather few > uninterned pinned symbols so using a small auxiliary array makes sense.= > But I'd rather we don't pay attention to a symbol's interned status, so= > we can later unintern them. Sure. But why would you ever want to unintern a symbol that pure storage references? --mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQbVzAAoJEMAaIROpHW7IvWEP/0Xc2efhDMmC6BnJ+7OalQg4 9Q/xVYUdVS6SG4rLWmJW1n3C9z+4+by1CB3lNtv4h/MisD89s8VZGl2qG+GrHTWO 2dy1PitjKj8DWuyLcOjYsBbkk5mBytmrPlooFQLW6pwjBLwh9IivNpIB7ge6Cmwd Dio7UST7UX+6LIZ1RY1wxxQPVjM6SrJaLF4+DCvuMZOyo/vdRcfaDKIkiQCtJ9yx El9TrIZBMHtZJaidShd0C+Fz2EeNJW3PQsqN3ThRapagwWPqYfyL2lisEHE+M/Jr 7EUvBBgBd0j081FTPjIxpM+3MltvMgTguIrauTR31wGooy0OXAvXzVijcjYWVSg2 g7/y/p05bNyInjb6X4XVPFCFT2HN27Y5W/UxFAobE2NGYWBzbaePtG4sHMkcQ7a5 F3diPQIazYxW2Apf13g2OvddUXr5uMxa4YwUgJ4Pzps2e11OiPxon1UQMe6pCQ6A Uxwc4QB9aGAlHW6QEnhm7jm61tShQPiWnowQq9LzuYapWwxv6A7o0cFop9fgKiU1 aZ4DsVJ09i/MPhiRXGkhrK0KyEGA/+B9wo1oYGw3ge2IJRujHKrcTdKt7S7CXiA5 CdWQIgG5HRqAWcCSDiMZz+qJGPmHQDkwqh0W96zSalYozoya4II9vALVHcYeBnqg SZJbX7Kf+BHhVNGt7j+I =iBVb -----END PGP SIGNATURE----- --mcgNLrsOLpMiVR2Sm3LTI8BCp5gdmCGbB--