From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18805 invoked by alias); 4 Jun 2002 16:33:26 -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 18671 invoked from network); 4 Jun 2002 16:33:21 -0000 Received: from unknown (HELO pizda.ninka.net) (216.101.162.242) by sources.redhat.com with SMTP; 4 Jun 2002 16:33:21 -0000 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id JAA20781; Tue, 4 Jun 2002 09:30:10 -0700 Date: Tue, 04 Jun 2002 09:35:00 -0000 Message-Id: <20020604.093009.90822622.davem@redhat.com> To: espie@nerim.net Cc: gcc@gcc.gnu.org Subject: Re: Speeding up GC From: "David S. Miller" In-Reply-To: <20020604180440.B7412@tetto.liafa.jussieu.fr> References: <200206041508.g54F8pK03041@quatramaran.ens.fr> <20020604.085207.37155289.davem@redhat.com> <20020604180440.B7412@tetto.liafa.jussieu.fr> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00229.txt.bz2 From: Marc Espie Date: Tue, 4 Jun 2002 18:04:40 +0200 1/ it may be prohibitively expensive on most OSes that implement it. I don't question this. 2/ Here, documentation of mprotect says: Not all implementations will guarantee protection on a page basis; the granularity of protection changes may be as large as an entire re- gion. In reality, %99 of UNIX systems do page based granularity because so many apps need it. ELF shared libraries are challenging, at best, if you don't do page based mprotect :-) It's a moot point because I think the mprotect+SIGSEGV thing is stupid from a performance standpoint anyways.