Request Review: 6902182: Starting with jdwp agent should not incur performance penalty

Deneau, Tom tom.deneau at
Mon Jan 4 11:34:23 PST 2010

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

New webrev is at

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

   * 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

   * 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

More information about the hotspot-compiler-dev mailing list