From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21991 invoked by alias); 3 Sep 2010 15:40:36 -0000 Received: (qmail 21980 invoked by uid 22791); 3 Sep 2010 15:40:35 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Sep 2010 15:40:00 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o83Fdwt3000913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Sep 2010 11:39:58 -0400 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o83FduLg008580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2010 11:39:58 -0400 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o83Fdui4003420; Fri, 3 Sep 2010 17:39:56 +0200 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o83FdtI6003419; Fri, 3 Sep 2010 17:39:55 +0200 Date: Fri, 03 Sep 2010 16:14:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: Doug Evans , gdb-patches@sourceware.org Subject: Re: [patch] Fix DW_OP_call2 and DW_OP_call4 for max-cache-age 0 Message-ID: <20100903153955.GA3236@host1.dyn.jankratochvil.net> References: <20100823185008.GA2926@host1.dyn.jankratochvil.net> <20100902160216.GA10848@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00129.txt.bz2 On Fri, 03 Sep 2010 17:35:50 +0200, Tom Tromey wrote: > I don't get the rationale for putting it in prepare_execute_command. > If we are flushing the cache based on memory use, then we only need to > consider flushing it just before we read a CU. There is currently no way of "locking" CUs. Some processing may arbitrarily access more and more CUs, and even the previous ones. Processing may need generally unlimited number of CUs, therefore it can reach the limit and flush still referenced CU. Therefore I find prepare_execute_command as the only safe place to flush any CU. (I may miss there exist some more strict rules than I am aware of.) Thanks, Jan