From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wojciech Meyer Newsgroups: gmane.emacs.devel Subject: Re: Compiling Elisp to a native code with a GCC plugin Date: Tue, 14 Sep 2010 22:29:35 +0100 Message-ID: <87wrqo2ev4.fsf@gmail.com> References: <87bp805ecr.fsf@gmail.com> <874ods5ctf.fsf@gmail.com> <877hio3urh.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1284499832 15270 80.91.229.12 (14 Sep 2010 21:30:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Sep 2010 21:30:32 +0000 (UTC) Cc: Wojciech Meyer , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 14 23:30:30 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ovd59-0006D8-9n for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 23:30:27 +0200 Original-Received: from localhost ([127.0.0.1]:33024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovd58-0006QD-LA for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 17:30:26 -0400 Original-Received: from [140.186.70.92] (port=45787 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovd4z-0006OX-5T for emacs-devel@gnu.org; Tue, 14 Sep 2010 17:30:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ovd4x-0007yc-US for emacs-devel@gnu.org; Tue, 14 Sep 2010 17:30:17 -0400 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:44970) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ovd4x-0007yK-Pf for emacs-devel@gnu.org; Tue, 14 Sep 2010 17:30:15 -0400 Original-Received: by wwb24 with SMTP id 24so8690689wwb.30 for ; Tue, 14 Sep 2010 14:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=sdoZx07BA6Gp3sNQHHqH2WHjyNeTerzRClRo/tGIcuI=; b=LG57eJPjNwexAp14FT+qhMkwSrgeHxhORPBXBWggPjc4I6cCI3rD7b2DgRHQ8KK9K+ kYuof+gI8A09EeoHIN6jSDM+C7sA2jA9fdNviF6HOvaXtWgFdWMN9Hv1vKmYXONk7wjn HEYxLcd+4fvoqFR/9xuAQcFOmspBFBwg13LqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=GRl/DL/2GfQNMqWIfqBIf1KlxVWui+3z7FRIprVCnTh36GMLb4FeqYF+SMFQ11T9/T PG0NN9r+4ggJ19C6beAj3ghVuepH6wv1Om4Pbhj6VWOKmvpDklohtLo29lpG017Ki/Th g71KlwyPLYchmdgq/AKB16wUYBVYReJdQJ0I4= Original-Received: by 10.216.10.145 with SMTP id 17mr485397wev.27.1284499814652; Tue, 14 Sep 2010 14:30:14 -0700 (PDT) Original-Received: from spec-desktop.specuu.com (host86-133-35-46.range86-133.btcentralplus.com [86.133.35.46]) by mx.google.com with ESMTPS id p82sm484319weq.27.2010.09.14.14.30.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Sep 2010 14:30:13 -0700 (PDT) In-Reply-To: (Tom Tromey's message of "Tue, 14 Sep 2010 15:16:55 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130155 Archived-At: Tom Tromey writes: >>>>>> "Wojciech" == Wojciech Meyer writes: > > Tom> It could be done. It just requires someone willing to do the work. > > Wojciech> I know. I could get my old sources of generational garbage > Wojciech> collector, to work. However it is a daunting job (the worse I > Wojciech> could imagine, garbage collectors are nasty), plugging and > Wojciech> debugging a new garbage collector to such huge and esoteric (I > Wojciech> am sure people that who've been working on Emacs for years > Wojciech> will not take this words badly and understand straight away > Wojciech> what I am (a newbie) talking about) project like > Wojciech> Emacs. However I might try to experiment with it (however > Wojciech> unfortunately I am not that self confident about it ;) ). > > It is always ok to ask for help. Thanks, I will keep in mind it. > > The current collector is very simple to understand. If you read > alloc.c, and look through the data structures representing lisp objects > (in lisp.h), you will have a pretty good idea of what is going on. It's open already :). > > > FWIW, I looked at writing an incremental collector for Emacs. I was > primarily interested in using software write barriers... this turns out > to be hard because there is a lot of code in Emacs of the form: > > FIELD_ACCESSOR (object) = value; > > ... which for a software barrier has to be converted to: > > SET_FIELD_ACCESSOR (object, value); Yep, we would need barriers for the second heap. For young heap it is OK to just scan it. > > (There are other bad things, too, like passing around a Lisp_Object* > that points to the contents of a vector.) > > So, lots of grunge work, just to get the point where you could start > actually working on the GC. I would look at automated rewriting to > make this work -- that worked out great on the concurrent branch. Maybe that work should be actually done even without thinking currently about GC. AFAIR MT Emacs rewriting was in Elisp, ideally maybe using GCC would be better at some point. > > > There was a more real attempt based on the Boehm GC. I think the bits > from that are still on a branch. This GC has a generational mode that, > IIRC, is based on memory protection bits. > Conservative Boehm will not bring much gain (I would think certainly loss) of performance. However I didn't know about marking pointers based on memory protection bits and that sounds interesting. Need to look at it. (however I am fully convinced that custom GC would be a superior option). > Tom Wojciech