Request Review: 6902182: Starting with jdwp agent should not incur performance penalty
Deneau, Tom
tom.deneau at amd.com
Mon Jan 4 11:34:23 PST 2010
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
More information about the serviceability-dev
mailing list