From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32266 invoked by alias); 1 Aug 2006 15:09:04 -0000 Received: (qmail 32257 invoked by uid 22791); 1 Aug 2006 15:09:03 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 Aug 2006 15:08:59 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k71F8vjc021524 for ; Tue, 1 Aug 2006 11:08:57 -0400 Received: from localhost.localdomain (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k71F8nNe017442; Tue, 1 Aug 2006 11:08:49 -0400 Received: from localhost.localdomain.redhat.com (vpn50-108.rdu.redhat.com [172.16.50.108]) by localhost.localdomain (8.13.1/8.12.8) with ESMTP id k71F8let013032; Tue, 1 Aug 2006 11:08:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.27921.726060.852247@localhost.localdomain> Date: Tue, 01 Aug 2006 15:09:00 -0000 To: Kyle Galloway Cc: tromey@redhat.com, java-patches@gcc.gnu.org Subject: Re: RFA: Changes to interpreter to avoid non-debugging slowdown In-Reply-To: <44CF58ED.2080302@redhat.com> References: <44CA8B0D.5030108@redhat.com> <17614.19859.287888.443036@localhost.localdomain> <44CF58ED.2080302@redhat.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2006-q3/txt/msg00244.txt.bz2 >>>>> "Kyle" == Kyle Galloway writes: Tom> We talked about it offline and the idea is, we need to track the types Tom> of stack and local variable slots while interpreting if the debugging Tom> code is enabled. However, we don't want to do this unconditionally as Tom> it adds overhead to interpretation. So, I looked at JVMTI a little more. It seems that we only need to know the types of locals, is that correct? I'm wondering now if it is worthwhile to make an entire second interpreter just for this. Perhaps an extra store in the various 'store' instructions is not too much overhead. Are there other reasons we may want a special debug-only interpreter? I thought Keith said there were, but I don't recall why exactly... That said, your updated patch is looking pretty good to me. One more addition I didn't think of yesterday: you have to update stacktrace.cc to account for the new interpreter. Tom