[RFA/JVMTI] SetEventNotificationMode and SetEventCallbacks

[Keith Seitz]

Tom Tromey wrote:

> 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"?

That hadn't occurred to me. I'll do that instead. Thanks!!

> 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'.

[You mean 'false'?] Done.

> 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.

Hmm. Yeah, I suppose I could do something like that. Although I've 
tested this quite a bit, I'm not entirely sure the new cast in this 
function (check_enabled_event) is legal. Alas, gcc doesn't give any 
warnings on this. Could you please scrutinize this?

Keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jvmti-events-new.patch
Type: text/x-patch
Size: 26516 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20060908/c201e75c/attachment.bin>