hotspot-runtime-dev Digest, Vol 41, Issue 14

[Tony Guan]

Hi Keith, Hi Poonam,

Thank  you for the advice, I will try in the direction of JVMTI then.

Best Regards,

Tony (Xiaohua Guan)



On Mon, Nov 22, 2010 at 2:00 PM,
<hotspot-runtime-dev-request at openjdk.java.net> wrote:
> Send hotspot-runtime-dev mailing list submissions to
>        hotspot-runtime-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mail.openjdk.java.net/mailman/listinfo/hotspot-runtime-dev
> or, via email, send a message with subject or body 'help' to
>        hotspot-runtime-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>        hotspot-runtime-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-runtime-dev digest..."
>
>
> Today's Topics:
>
>   1. instrumenting java classes INSIDE the jvm (Tony Guan)
>   2. Re: instrumenting java classes INSIDE the jvm (Poonam Bajaj)
>   3. Re: instrumenting java classes INSIDE the jvm (Keith McGuigan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Nov 2010 01:19:07 -0600
> From: Tony Guan <guanxiaohua at gmail.com>
> Subject: instrumenting java classes INSIDE the jvm
> To: hotspot-runtime-dev at openjdk.java.net
> Message-ID:
>        <AANLkTikg8W7f4MxRqUhJyt5+1HVnTNcvzsdRupkoiKr8 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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.
>
> Currently, I am intercepting SharedRuntime::dtrace_method_entry() to
> insert my own code inside hotspot. While this works, the performance
> is really terrible. Because I have to compare each method call with
> the right one, and the string comparison happens for every method call
> under the class type C.
>
> So I am looking for a way to insert some code at the beginning of a
> CERTAIN method call, to avoid the need of instrumenting or monitoring
> EVERY method call.
>
> 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.
>
> Currently I want to mark the class and the method upon class loading,
> and to do the comparison in SharedRuntime::dtrace_method_entry(). This
> should avoid the need to do the string comparison, but still need to
> monitor every method call, which is an overhead that we really want to
> get rid of.
>
> Thanks a lot!
>
> Tony
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 22 Nov 2010 13:55:53 +0530
> From: Poonam Bajaj <poonam.bajaj at oracle.com>
> Subject: Re: instrumenting java classes INSIDE the jvm
> To: Tony Guan <guanxiaohua at gmail.com>
> Cc: hotspot-runtime-dev at openjdk.java.net
> Message-ID: <4CEA2911.1090902 at oracle.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Tony,
>
> Have you explored doing this using Dynamic Bytecode Instrumentation
> using JVMTI's redefineClass(Class[] classes*, *byte[][] newBC) method.
>
> http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/
> http://weblogs.java.net/blog/kellyohair/archive/2005/05/bytecode_instru.html
>
> Thanks,
> Poonam
>
> On 11/22/2010 12:49 PM, 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.
>>
>> Currently, I am intercepting SharedRuntime::dtrace_method_entry() to
>> insert my own code inside hotspot. While this works, the performance
>> is really terrible. Because I have to compare each method call with
>> the right one, and the string comparison happens for every method call
>> under the class type C.
>>
>> So I am looking for a way to insert some code at the beginning of a
>> CERTAIN method call, to avoid the need of instrumenting or monitoring
>> EVERY method call.
>>
>> 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.
>>
>> Currently I want to mark the class and the method upon class loading,
>> and to do the comparison in SharedRuntime::dtrace_method_entry(). This
>> should avoid the need to do the string comparison, but still need to
>> monitor every method call, which is an overhead that we really want to
>> get rid of.
>>
>> Thanks a lot!
>>
>> Tony
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101122/efbe4bc6/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 22 Nov 2010 08:49:04 -0500
> From: Keith McGuigan <keith.mcguigan at oracle.com>
> Subject: Re: instrumenting java classes INSIDE the jvm
> To: hotspot-runtime-dev at openjdk.java.net
> Message-ID: <4CEA74D0.4020802 at oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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.
>
> --
> - Keith
>
>
> End of hotspot-runtime-dev Digest, Vol 41, Issue 14
> ***************************************************
>