From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10765 invoked by alias); 10 Dec 2003 19:27:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10752 invoked from network); 10 Dec 2003 19:27:23 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 10 Dec 2003 19:27:23 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id hBAJRNLh012090 for ; Wed, 10 Dec 2003 11:27:23 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 10 Dec 2003 11:27:20 -0800 Received: from [17.219.199.154] ([17.219.199.154]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hBAJQi0m001536; Wed, 10 Dec 2003 11:26:44 -0800 (PST) In-Reply-To: <4195D82C2DB1D211B9910008C7C9B06F01F373E6@lr0nt3.lr.tudelft.nl> References: <4195D82C2DB1D211B9910008C7C9B06F01F373E6@lr0nt3.lr.tudelft.nl> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'gcc@gcc.gnu.org'" From: Geoffrey Keating Subject: Re: Some GC marking inefficiency with chain_next and chain_prev Date: Wed, 10 Dec 2003 21:47:00 -0000 To: "S. Bosscher" X-SW-Source: 2003-12/txt/msg00635.txt.bz2 On 10/12/2003, at 3:21 AM, S. Bosscher wrote: > In other words, first we go over the next and prev chains because > of the GTY markers "chain_next" and "chain_prev". Then we look > at those fields again in the loop, calling ggc_set_mark() on the > prev and next fields again, but this has no effect since we've > already marked them. I noticed this when these options were implemented, but I couldn't see an easy to fix it without parsing the arguments to chain_next and chain_prev and knowing a lot about structure layout. It's not a significant cost, since the data will already be in cache. If you don't need chain_prev and chain_next, you shouldn't use them. When I tried automatically putting chain_next on every structure that looked like it could use it (*with* the improvement you suggest above, since if it's automatic you know which field doesn't need marking), GC slowed down measurably.