From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4254 invoked by alias); 1 May 2002 22:12:52 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 4240 invoked from network); 1 May 2002 22:12:50 -0000 Received: from unknown (HELO tomago.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 May 2002 22:12:50 -0000 Received: (from graydon@localhost) by tomago.toronto.redhat.com (8.11.6/8.11.6) id g41MCnZ03183; Wed, 1 May 2002 18:12:49 -0400 Date: Wed, 01 May 2002 15:12:00 -0000 From: Graydon Hoare To: binutils@sources.redhat.com Cc: cgen@sources.redhat.com Subject: closing and re-opening CPUs in opcodes Message-ID: <20020501181249.C1999@tomago.toronto.redhat.com> Reply-To: graydon@redhat.com Mail-Followup-To: binutils@sources.redhat.com, cgen@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-SW-Source: 2002-q2/txt/msg00002.txt.bz2 Hi, When doing multi-CPU simulation in sid, on cgen-generated CPU cores, with --trace-disassemble, opcodes is called once per insn to do the disassembly. If two calls come with different CPU description handles, opcodes will *notice* this fact, via a static handle it keeps in function scope telling it how it was last called, and close/re-open the handle it's being called with. This has a couple penalties associated with it. First, it reveals a number of hidden memory leaks between CPU description open and close (and I've not found all of them yet). Second, it is actually quite expensive in terms of simulator cycles, since we re-initialize a bunch of tables, rebuild assembly regexes, etc. every time we re-open a CPU description. When you run with large-ish blocks between CPU yields, this is not too bad. When you run the CPUs in lock-step, to give a good "simulated concurrency", it is intolerably slow (and quickly eats all available memory). Is there any particular reason why, in opcodes' "handle oriented" interface, we're closing and re-opening? Shouldn't the handles isolate all the resources they're responsible for? I'll keep digging, but any additional insight would be appreciated. -graydon