From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: tags in the 3 lowest bits Date: 23 Nov 2003 19:08:36 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069632622 14103 80.91.224.253 (24 Nov 2003 00:10:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2003 00:10:22 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Nov 24 01:10:19 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AO4J1-0007LZ-00 for ; Mon, 24 Nov 2003 01:10:19 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AO4J0-0002NZ-00 for ; Mon, 24 Nov 2003 01:10:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AO5G3-0004pM-Sa for emacs-devel@quimby.gnus.org; Sun, 23 Nov 2003 20:11:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AO5FX-0004mp-21 for emacs-devel@gnu.org; Sun, 23 Nov 2003 20:10:47 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AO5Ew-0004eq-TG for emacs-devel@gnu.org; Sun, 23 Nov 2003 20:10:42 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AO5Ew-0004eU-4q for emacs-devel@gnu.org; Sun, 23 Nov 2003 20:10:10 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (8.12.9/8.12.9) with ESMTP id hAO08abj020944; Sun, 23 Nov 2003 19:08:36 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 70E113C63E; Sun, 23 Nov 2003 19:08:36 -0500 (EST) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner: Found to be clean X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18065 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18065 >> Of course, an alternative would be to switch to BoehmGC. > Sure, but is it a better alternative? And why? It would make array allocation much cheaper. Now that's obviously not consdered as an important part of the elisp engine since it hasn't been optimized, so it can't be a main motivation for switching to BoehmGC. > How does that remove the dependency on (non-aligned) mallocs? BoehmGC does its own malloc, so it would solve it in the same way that using emacs/src/gmalloc.c can solve it. > I can understand your changes in the scope of the current GC scheme(s). > Adding another one together with your changes doesn't seem necessary to me. The two aren't linked indeed. >> Dave Love has started work on this and it would be interesting to see >> how it works out in practice (what kind of impact it has on memory >> footprint and CPU usage). > What is the status of that effort? Dave? > IMHO, this is not a user-visible change, so I think we have more > important things to work on. The BoehmGC is a pretty good package. Its performance can be pretty good and it can offer things like incremental collection which can make a visible difference to the users. Of course it does not always work great, it all depends on the actual application and might require some tuning. But if the performance is there, it would also have the advantage of saving us from worrying about GC: we could scrap the GC code and rely on a well-maintained piece of code. Now, that doesn't mean that it should be a top-priority objective, but just that working on it is not necessarily a waste of time. Stefan