instrumenting java classes INSIDE the jvm
keith.mcguigan at oracle.com
Mon Nov 22 05:49:04 PST 2010
On 11/22/2010 02:19 AM, Tony Guan wrote:
> Dear all,
> I want to do something special once a method M is called for some type
> of class C, mainly to changed the policy of gc.
> I understand that this can be done with some java agent, but my
> implementation need to be able to call into the JVM, so that the GC
> behavior can be changed. That means I need to let the hotspot know
> once method M of class C is called, not a standalone java program.
If you want this to perform well, you probably don't want to write your
instrumentation directly in the JVM where every method is affected.
Better would be to split out your implementation so that the method
selection happens outside the JVM, and calls the JVM when you want to
change a parameter.
You'll need some native entry point into the JVM. One way is to simply
add one in the style of the JVM_* methods in jvm.cpp, and then call that
entry point from a native method (JNI) that you write and link with
libjvm.so. Or, you can use the Unsafe mechanism to call into the JVM
directly from Java.
In either case, you'll also need to use some mechanism to cause your
entry point to be executed when you want it to be. If you know
beforehand what class/method you want, you ought to be able to simply
change the source code for that method in the JDK to call your new
native method (or Unsafe method). If you want to have the ability to
pick any arbitrary method, then probably the most efficient method would
be a java agent that does bytecode instrumentation. Another simpler
possibility may be to use a native JVMTI agent that can use more
selective event notifications.
More information about the hotspot-runtime-dev