From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8361 invoked by alias); 6 Sep 2006 22:26:44 -0000 Received: (qmail 8353 invoked by uid 22791); 6 Sep 2006 22:26:43 -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; Wed, 06 Sep 2006 22:26:39 +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 k86MQbUC025548 for ; Wed, 6 Sep 2006 18:26:37 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k86MQbaL022529 for ; Wed, 6 Sep 2006 18:26:37 -0400 Received: from opsy.redhat.com (IDENT:Zp3GN3VWqIRikJsM2US/jPoPe3oYdsiZ@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.13.1/8.12.8) with ESMTP id k86MQaZ9027281; Wed, 6 Sep 2006 18:26:36 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 5803F5080C1; Wed, 6 Sep 2006 16:20:43 -0600 (MDT) To: Keith Seitz Cc: Java Patch List Subject: Re: [RFA/JVMTI] SetEventNotificationMode and SetEventCallbacks References: <44F8836D.90006@redhat.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Wed, 06 Sep 2006 22:26:00 -0000 In-Reply-To: <44F8836D.90006@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00395.txt.bz2 >>>>> "Keith" == Keith Seitz writes: Keith> This patch implements the two JVMTI functions $subject. As you can Keith> imagine, JVMTI event notifications in libgcj are going to be quite Keith> invasive. Hoping to minimize the damage from this, I've adopted Keith> basically the same technique that I was using with JDWP and Keith> Jdwp::isDebugging. The overall plan here looks reasonable to me. Keith> +/* A global bit field to help limit the impact of JVMTI on normal Keith> + operations. Unset fields (events) mean no JVMTI environment requested Keith> + that event type. */ A couple questions here. One is, do we really want a bit field? I'm concerned that some events will occur in places where we really want to be cycle-shaving, perhaps plain booleans would be better. The other is, would a namespace be "more C++-like"? Keith> +/* A macro to test whether an event should be posted to JVMTI.*/ Keith> +#define JVMTI_REQUESTED_EVENT(Event) (_Jv_JVMTI_RequestedEvents.Event == 1) Perhaps this should be wrapped in __builtin_expect, and expect 'no'. Keith> +#define CHECK_EVENT(Event) Avoiding a bit-field would let you simplify this code somewhat. Not that it matters much, I suppose, but this code could then be parameterized by field offset or by pointer-to-global, instead of having a loop in each branch of the switch. Tom