The following line in init_onload_capabilities() has been
there since revision 1.1 of the file:

  // jc.can_get_monitor_info = 1;

and is not listed in any other capability init function.
It was added to init_always_capabilities() by the
following delta:

src/share/vm/prims/SCCS/s.jvmtiManageCapabilities.cpp:

D 1.3.1.1 03/04/09 15:07:01 swamyv 8 6 00001/00000/00316
MRs:
COMMENTS:
4639363 : Added can_get_monitor_info potential capability.
The fix for the following bug:

    6431456 2/3 Agents should always be able to get can_tag_objects
                capability in live phase

added the following in init_always_capabilities():

+ jc.can_tag_objects = 1;
+ jc.can_generate_object_free_events = 1;

but neglected to remove the two capabilities from
init_onload_capabilities():

116 jc.can_tag_objects = 1;
117 jc.can_generate_object_free_events = 1;

They should be removed.

The fix for 6431456 was integrated in Mustang-B89.
The fix for the following bug:

    6943485 3/3 JVMTI always on capabilities change code generation too much

removed the JvmtiExport::_can_examine_or_deopt_anywhere flag.

Here's the diff for the logic that set the flag:

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/diff/b4776199210f/src/share/vm/prims/jvmtiManageCapabilities.cpp

changeset 1395 b4776199210f
parent 1208 6deeaebad47a
child 1473 c18cbe5936b8

--- a/src/share/vm/prims/jvmtiManageCapabilities.cpp Mon Feb 01 17:35:05 2010 -0700
+++ b/src/share/vm/prims/jvmtiManageCapabilities.cpp Mon Apr 26 23:59:45 2010 -0700
@@ -332,16 +332,6 @@ void JvmtiManageCapabilities::update() {
}
JvmtiExport::set_can_get_source_debug_extension(avail.can_get_source_debug_extension);
- JvmtiExport::set_can_examine_or_deopt_anywhere(
- avail.can_generate_breakpoint_events ||
- interp_events ||
- avail.can_redefine_classes ||
- avail.can_retransform_classes ||
- avail.can_access_local_variables ||
- avail.can_get_owned_monitor_info ||
- avail.can_get_current_contended_monitor ||
- avail.can_get_monitor_info ||
- avail.can_get_owned_monitor_stack_depth_info);
JvmtiExport::set_can_maintain_original_method_order(avail.can_maintain_original_method_order);
JvmtiExport::set_can_post_interpreter_events(interp_events);
JvmtiExport::set_can_hotswap_or_post_breakpoint(
@@ -353,10 +343,13 @@ void JvmtiManageCapabilities::update() {
avail.can_generate_all_class_hook_events);
JvmtiExport::set_can_walk_any_space(
avail.can_tag_objects); // disable sharing in onload phase
+ // This controls whether the compilers keep extra locals live to
+ // improve the debugging experience so only set them if the selected
+ // capabilities look like a debugger.
JvmtiExport::set_can_access_local_variables(
- avail.can_access_local_variables ||
- avail.can_redefine_classes ||
- avail.can_retransform_classes);
+ avail.can_access_local_variables ||
+ avail.can_generate_breakpoint_events ||
+ avail.can_generate_frame_pop_events);
JvmtiExport::set_can_post_on_exceptions(
avail.can_generate_exception_events ||
avail.can_generate_frame_pop_events ||


I think that some of the capabilities used by the logic that set
the _can_examine_or_deopt_anywhere flag were placed in the
init_onload_capabilities() method because they were used by
the _can_examine_or_deopt_anywhere flag. The flag is present
in revision 1.1 and can_get_owned_monitor_info has been part
of that logic since day 1 also.

For example:

    can_get_owned_monitor_info
    can_get_owned_monitor_stack_depth_info
    can_get_current_contended_monitor

are no longer dependent on any other code in HotSpot after
the fix for 6943485. The other capabilities that used to be
queried in the setting of the _can_examine_or_deopt_anywhere
flag also need to be examined.

The fix for 6943485 was integrated in HSX-18-B04/JDK7-B92.