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: Sun, 26 Nov 2017 00:11:01 -0500 Message-ID: References: <9d7be625-85ae-54d5-3897-6f701c8ea124@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1511673080 21054 195.159.176.226 (26 Nov 2017 05:11:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 05:11:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Pip Cet , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 26 06:11:15 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 1eIpDm-00055T-Pk for ged-emacs-devel@m.gmane.org; Sun, 26 Nov 2017 06:11:14 +0100 Original-Received: from localhost ([::1]:55280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIpDu-0000SP-7p for ged-emacs-devel@m.gmane.org; Sun, 26 Nov 2017 00:11:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIpDl-0000S9-4w for emacs-devel@gnu.org; Sun, 26 Nov 2017 00:11:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIpDh-0005l8-4F for emacs-devel@gnu.org; Sun, 26 Nov 2017 00:11:13 -0500 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:49418) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIpDg-0005l1-V8 for emacs-devel@gnu.org; Sun, 26 Nov 2017 00:11:09 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FJDgC4TBpa/9Iwq8BaDhABBgyDPCc/b?= =?us-ascii?q?ieJDIYHjiEBgXw0AZgGQymFFgQCAoRdRBQBAQEBAQEBAQEDaCiCa0gmMgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARoCDUMBGgEEAVYjEAs0EhQYDSSKLQgQp3uKewEBAQEGAgElg?= =?us-ascii?q?zqFRYMrh3QMgxQFkwqPPIdyjzCJXjWHJYx2in42I4FQMhoIMBaCTQiEDV0jNwG?= =?us-ascii?q?KZgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FJDgC4TBpa/9Iwq8BaDhABBgyDPCc/bieJDIYHjiEBgXw?= =?us-ascii?q?0AZgGQymFFgQCAoRdRBQBAQEBAQEBAQEDaCiCa0gmMgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RoCDUMBGgEEAVYjEAs0EhQYDSSKLQgQp3uKewEBAQEGAgElgzqFRYMrh3QMgxQ?= =?us-ascii?q?FkwqPPIdyjzCJXjWHJYx2in42I4FQMhoIMBaCTQiEDV0jNwGKZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,456,1505793600"; d="scan'208";a="10330599" Original-Received: from 192-171-48-210.cpe.pppoe.ca (HELO pastel.home) ([192.171.48.210]) by smtp.teksavvy.com with ESMTP; 26 Nov 2017 00:11:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 4880C60568; Sun, 26 Nov 2017 00:11:01 -0500 (EST) In-Reply-To: <9d7be625-85ae-54d5-3897-6f701c8ea124@cs.ucla.edu> (Paul Eggert's message of "Sat, 25 Nov 2017 20:20:53 -0800") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 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:220458 Archived-At: >> But it's not like it doesn't have downsides. > ... and then you stopped writing! Just when you were getting to the good part! Off the top of my head: - `sxhash-eq` is a lot more painful to implement. - during GC you need *double* the heap space. If you only GC a sub-part of your heap (e.g. just one generation), then you only need double that sub-part. So if you only use a copy-GC for the youngest generation it's not a big deal, but if you use stop© over your whole heap, we're talking about a 100% overhead on memory usage. - interaction with C code is significantly more tricky since you really need to find *all* the pointers into your objects, including random transient ones that aren't Lisp_Object. Often, the only sane way out is to disallow access to the actual pointers from C: e.g. the C code only manipulates "handles" into an array of actual pointers. - the most obvious concurrent-GC for stop© requires a read-barrier rather than a write-barrier. But I do recommend taking a look at the TI Explorer II's garbage collector, described in the article below. It's making a really neat use of the read-barrier! Stefan @Article{Courts88, author = {Robert Courts}, title = {Improving locality of reference in garbage-collecting memory management system}, journal = CACM, year = 1988, volume = 31, number = 9, pages = {1128-1138}, doi = {http://doi.acm.org/10.1145/48529.48536}, xnote = {TI Explorer II's GC!!}, abstract = {Modern Lisp systems make heavy use of a garbage-collecting style of memory management. Generally, the locality of reference in garbage-collected systems has been very poor. In virtual memory systems, this poor locality of reference generally causes a large amount of wasted time waiting on page faults or uses excessively large amounts of main memory. An adaptive memory management algorithm, described in this article, allows substantial improvement in locality of reference. Performance measurements indicate that page-wait time typically is reduced by a factor of four with constant memory size and disk technology. Alternately, the size of memory typically can be reduced by a factor of two with constant performance.} }