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@openjdk.java.net';
'hotspot-compiler-...@openjdk.java.net'
Cc: 'daniel.daughe...@sun.com'
Subject: RE: Request Review: 6902182: Starting with jdwp agent should not incur
performance penalty
Cross posting to hotspot-compiler-...@openjdk.java.net and
serviceability-dev@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
