From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29671 invoked by alias); 21 Aug 2009 07:48:02 -0000 Received: (qmail 29639 invoked by uid 22791); 21 Aug 2009 07:48:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f226.google.com (HELO mail-ew0-f226.google.com) (209.85.219.226) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Aug 2009 07:47:55 +0000 Received: by ewy26 with SMTP id 26so462958ewy.29 for ; Fri, 21 Aug 2009 00:47:52 -0700 (PDT) Received: by 10.210.39.11 with SMTP id m11mr841009ebm.27.1250840872740; Fri, 21 Aug 2009 00:47:52 -0700 (PDT) Received: from yakj.usersys.redhat.com (nat-pool-brq.redhat.com [62.40.79.66]) by mx.google.com with ESMTPS id 24sm7661855eyx.3.2009.08.21.00.47.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Aug 2009 00:47:51 -0700 (PDT) Message-ID: <4A8E5127.50709@gnu.org> Date: Fri, 21 Aug 2009 09:37:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 MIME-Version: 1.0 To: Laurynas Biveinis CC: gcc@gcc.gnu.org Subject: Re: Work on gc-improv branch References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00386.txt.bz2 > 1) Stop abusing current GC by allocating structures there that GC > knows nothing about, i.e. there is never a path from GC roots to any > variables of that type and so gengtype does not produce markers it. That's good. > BTW, it does not deal with types that in some instances have variables > allocated in proper GC way (with a path from GC root) and in some > instances not. Fixing these is going to be hard. Do you have some examples? > This is a prerequisite for my future GC plans of advanced GC > implementation that will need to know type of object given its > address. Also it has a nice side effect of enforcing that GC is used > only with types that it knows something about (see 1) above). Makes a lot of sense. > I'd love to see this merged to trunk in near future too but I expect > that right now it would be seen as an arbitrary and annoying change by > developers, especially since nothing in GC implementation right now > makes use of it. Actually, now is a perfect time to do it (more precisely, after LTO is merged and before people start hacking on branches for 4.6). The only really active branch now is trans-mem. Paolo