On 12/29/15 23:52, Alan Bateman wrote:
On 28/12/2015 20:13, serguei.spit...@oracle.com wrote:
It would be nice to get rid of this JVM TI capability.
But my question is if new JVMTI functionality is mandatory for all
VM's out there.
I think we need to look at aligning the next version of JVM TI with
Java SE 9 and if this makes sense then it would mean the capability
isn't needed.
Ok, got it.
Thanks.
It also means that residual references to JDK 1.1 in the spec can be
dropped, I think these date back to JVMDI or JVMPI.
Do you mean to make a clean up and get rid of all occurrences of
since="1.1"?
cat -n src/share/vm/prims/jvmti.xml | g since | g '1\.1'
1468 <function id="GetCurrentThread" phase="start" num="18"
since="1.1">
1928 <function id="GetOwnedMonitorStackDepthInfo" num="153"
since="1.1">
2971 <function id="ForceEarlyReturnObject" num="81" since="1.1">
3021 <function id="ForceEarlyReturnInt" num="82" since="1.1">
3069 <function id="ForceEarlyReturnLong" num="83" since="1.1">
3112 <function id="ForceEarlyReturnFloat" num="84" since="1.1">
3155 <function id="ForceEarlyReturnDouble" num="85" since="1.1">
3196 <function id="ForceEarlyReturnVoid" num="86" since="1.1">
3306 since="1.1">
3330 since="1.1">
3398 since="1.1">
3428 since="1.1">
3624 since="1.1">
3639 since="1.1">
3655 since="1.1">
3700 since="1.1">
3733 since="1.1">
3789 since="1.1">
3840 since="1.1">
4001 <callback id="jvmtiHeapIterationCallback" since="1.1">
4056 <callback id="jvmtiHeapReferenceCallback" since="1.1">
4160 <callback id="jvmtiPrimitiveFieldCallback" since="1.1">
4234 <callback id="jvmtiArrayPrimitiveValueCallback" since="1.1">
4300 <callback id="jvmtiStringPrimitiveValueCallback" since="1.1">
4363 <callback id="jvmtiReservedCallback" since="1.1">
4373 <function id="FollowReferences" num="115" since="1.1">
4608 <function id="IterateThroughHeap" num="116" since="1.1">
6888 <function id="GetClassVersionNumbers" phase="start"
num="145" since="1.1">
6932 <function id="GetConstantPool" phase="start" num="146"
since="1.1">
7071 <function id="IsModifiableClass" jkernel="yes"
phase="start" num="45" since="1.1">
7196 <function id="RetransformClasses" jkernel="yes" num="152"
since="1.1">
8434 <function id="SetNativeMethodPrefix" jkernel="yes"
phase="any" num="73" since="1.1">
8557 <function id="SetNativeMethodPrefixes" jkernel="yes"
phase="any" num="74" since="1.1">
9917 <capabilityfield id="can_force_early_return" since="1.1">
9923 <capabilityfield
id="can_get_owned_monitor_stack_depth_info" since="1.1">
9929 <capabilityfield id="can_get_constant_pool" since="1.1">
9935 <capabilityfield id="can_set_native_method_prefix"
since="1.1">
9942 <capabilityfield id="can_retransform_classes" since="1.1">
9959 <capabilityfield id="can_retransform_any_class" since="1.1">
9966 <capabilityfield
id="can_generate_resource_exhaustion_heap_events" since="1.1">
9973 <capabilityfield
id="can_generate_resource_exhaustion_threads_events" since="1.1">
10589 <function id="AddToSystemClassLoaderSearch" jkernel="yes"
phase="onload" num="151" since="1.1">
12951 since="1.1">
12961 since="1.1">
Just want to make sure I understand this correctly...
The JDWP agent uses JNI to upcall to Module::getClassLoader and
Module::canRead, we might consider adding JNI or JVM TI functions in
the future and avoid this.
I was thinking about the same.
My preference would be to add new JVM TI functions.
We can add these later, it's not critical to get these JDWP commands
working (as you've demonstrated).
Ok.
I put it in my todo list.
Thanks,
Serguei
-Alan.
