From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector Date: Sat, 25 Nov 2017 20:20:03 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1511659220 7021 195.159.176.226 (26 Nov 2017 01:20:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 01:20:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 26 02:20:12 2017 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 1eIlc7-00011V-Sr for ged-emacs-devel@m.gmane.org; Sun, 26 Nov 2017 02:20:08 +0100 Original-Received: from localhost ([::1]:54839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIlcE-0004aD-W1 for ged-emacs-devel@m.gmane.org; Sat, 25 Nov 2017 20:20:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIlc8-0004a8-TV for emacs-devel@gnu.org; Sat, 25 Nov 2017 20:20:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIlc5-0006fU-OU for emacs-devel@gnu.org; Sat, 25 Nov 2017 20:20:08 -0500 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:35956) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIlc5-0006eD-IW for emacs-devel@gnu.org; Sat, 25 Nov 2017 20:20:05 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GXDQB5FRpa/9Iwq8BaHQEBBQELAYM8g?= =?us-ascii?q?VSJM4YHjiABgXw0AZhJhT8EAgKEXUQUAQEBAQEBAQEBA2gohSEBBAFWIwULCzQ?= =?us-ascii?q?SFBgNJIotCKgninoBAQEHAiaDOohwixQFkwqPPKEAh1qXdDYjgVAyGggwgmOEc?= =?us-ascii?q?iOLHAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2GXDQB5FRpa/9Iwq8BaHQEBBQELAYM8gVSJM4YHjiABgXw?= =?us-ascii?q?0AZhJhT8EAgKEXUQUAQEBAQEBAQEBA2gohSEBBAFWIwULCzQSFBgNJIotCKgni?= =?us-ascii?q?noBAQEHAiaDOohwixQFkwqPPKEAh1qXdDYjgVAyGggwgmOEciOLHAEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,455,1505793600"; d="scan'208";a="9923779" Original-Received: from 192-171-48-210.cpe.pppoe.ca (HELO pastel.home) ([192.171.48.210]) by smtp.teksavvy.com with ESMTP; 25 Nov 2017 20:20:03 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id BA8D0606C5; Sat, 25 Nov 2017 20:20:03 -0500 (EST) In-Reply-To: (Pip Cet's message of "Sat, 25 Nov 2017 23:50:16 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.36 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:220456 Archived-At: >> This will only be acceptable if after the switch, invalid code >> (e.g. Lisp_Objects on the stack that aren't properly instrumented) >> is automatically detected. > Hmm. Is that for every build, or as a debugging option? The check doesn't have to be done for every build, but it needs to be static (i.e. performed during something like compile-time, not run-time). > You mean GCPRO? Yes. > I'm not sure what you mean by "not precise enough"; I'm referring to the problem you saw: ... but was defeated because some places didn't GCPRO variables that they knew to be protected by upstream callers... > I guess I'm an exceptional user, then, because I complain about it a > lot. It's very much in embarrassing-pause territory here. Interesting. I wonder what part of your use patterns would cause that. Do you remember of particular situations where this happens, or is it just kind of all the time? >> Also I think a non-moving GC will be a lot easier to accommodate. > I suspect that I don't fully understand the benefits of a moving GC, > because memory fragmentation alone simply has never been a problem > for me. A moving GC is not necessarily better. It's a popular choice in languages with high allocation rates, because allocation is extremely efficient (just move the allocation pointer forward) and because a stop© of the youngest generation can usually recover a lot of garbage with fairly little effort (because often there are much fewer live objects in the young region than dead ones, so copying the live objects is cheaper than (mark&)sweeping the dead ones). But it's not like it doesn't have downsides. Stefan