JvmtiTrace of Capabilities APIs

[Deneau, Tom]

While working on the webrev for 6902182, I noticed that when I used -XX:TraceJVMTI and traced calls that involved capabilities (for example, AddCapabilities), the individual capabilities bits were not displayed.  In jvmtiManageCapabilities.cpp, there is a function 
    JvmtiManageCapabilities:: print(const jvmtiCapabilities* cap)
which looks like it is set up to print this kind of individual capabilitiy information but I didn't see it getting called.

-- Tom


-----Original Message-----
From: Deneau, Tom 
Sent: Monday, January 04, 2010 1:34 PM
To: 'serviceability-dev at openjdk.java.net'; 'hotspot-compiler-dev at openjdk.java.net'
Cc: 'Daniel.Daugherty at Sun.COM'
Subject: RE: Request Review: 6902182: Starting with jdwp agent should not incur performance penalty

Cross posting to hotspot-compiler-dev at openjdk.java.net and
serviceability-dev at openjdk.java.net since this review request touches
both compiler/runtime code and JVMTI code...

New webrev is at http://cr.openjdk.java.net/~tdeneau/6902182/webrev.04

The compiler/runtime part has not changed too much:

   * Based on Dan's jvmti-related comments, the name of the
     JavaThread-specific flag is now should_post_on_exceptions

   * reduced the number of code lines in the common
     graphKit::uncommon_trap_if_should_post_on_exceptions

   * moved the BailoutToInterpreterForThrows logic above the
     jvmti_can_post_exceptions() check to avoid having two uncommon
     traps on both paths.


The jvmti part has changed/simplified quite a bit based on Dan Daugherty's good comments:

   * There is still a cached thread-specific flag called
     should_post_on_exceptions.  This flag is recalculated in only in
     JvmtiEventControllerPrivate::recompute_thread_enabled and is
     handled in a way similar to the thread-specific interp-only mode
     which was already in recompute_thread_enabled.

   * There is also a "global" should_post_on_exceptions flag which
     reflects whether ANY thread has one of the appropriate event
     notification bits set.  This flag is exposed in the normal
     JVMTI_SUPPORT_FLAG manner in jvmtiExport.cpp/hpp and updated in
     jvmtiEventControllerPrivate::recompute_enabled.  Unlike the
     thread-specific flag, this global flag is not yet used anywhere
     else but since it fits into the existing JVMTI_SUPPORT_FLAG
     structure, it was felt we should put it there for possible future
     use.

   * jvmtiEventController logic now handles all the events that were
     possible if jvmti_can_post_exceptions() was true.  These are
     Throws, Catches, FramePops, and MethodExits.

Note to Dan:

   * We had talked about changing the name of the existing
     jvmti_can_post_exceptions() to jvmti_can_post_on_exceptions() to
     make it match the new should_post_on_exceptions name used above.
     Since this affected some other files, to keep this webrev
     simpler, I decided not to do that as part of this webrev.  If we
     still want to do this, I can post this additional change as the
     final webrev.

-- Tom Deneau