From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19056 invoked by alias); 20 Jan 2011 04:19:13 -0000 Received: (qmail 19047 invoked by uid 22791); 20 Jan 2011 04:19:11 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Jan 2011 04:19:07 +0000 Received: by qwi2 with SMTP id 2so141711qwi.20 for ; Wed, 19 Jan 2011 20:19:05 -0800 (PST) Received: by 10.229.81.6 with SMTP id v6mr1344520qck.223.1295497143193; Wed, 19 Jan 2011 20:19:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.241.212 with HTTP; Wed, 19 Jan 2011 20:18:43 -0800 (PST) In-Reply-To: <20110119225145.GK6247@codesourcery.com> References: <20110119225145.GK6247@codesourcery.com> From: Laurynas Biveinis Date: Thu, 20 Jan 2011 05:50:00 -0000 Message-ID: Subject: Re: [gc-improv] Copy current trunk to branch To: Nathan Froyd Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg01360.txt.bz2 2011/1/20 Nathan Froyd : > On Wed, Jan 19, 2011 at 03:29:47PM +0200, Laurynas Biveinis wrote: >> I am re-using my merged gc-improv branch for my next memory management >> project, which is moving RTL out of GC and, time permitting, better GC >> implementation. I hope to merge it during 4.7 stage 1. > > This is excellent! =C2=A0Would you mind explaining what your plan is? > - Move RTL back to obstacks: global, per-function, scratch, maybe a few per-pass obstacks too. My work so far is based on Bernd Schmidt's patch [1]. Also this will enable quite a few cleanups: in gengtype, removal a lot of GTY markers in backends that only serve PCH. - Merge to trunk. - Add an object type tag to all GC allocated objects, this should be trivial now that GC allocation is type-strict. - Then the "normal" GC implementation techniques: incremental, copying, generational etc. all become doable. Implement, measure performance, merge, repeat. Currently I do not plan to remove the limitation that collection happens only when invoked explicitly with ggc_collect(). That would require solving the issue of GC roots on stack in one way or another. [1] - http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00655.html --=20 Laurynas