Re: [RFA/JVMTI] SetEventNotificationMode and SetEventCallbacks

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> 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