Howdy, I have been playing with the DVM provider, and am extremely excited to be able to dynamically observe various JVM events (especially garbage collection). Adam and Jarod''s presentation at JavaOne mentions that there is some performance impact when the DVM probes aren''t enabled, but I can''t seem to find any data to quantify this. Has anyone by any chance measured the performance impact of the DVM provider? Is anyone using the DVM provider in production? Thanks for any insight, - Ryan -- UNIX Administrator http://daemons.net/~matty
Matty''s email at 2/18/2006 12:57 PM, said:> > Howdy, > > I have been playing with the DVM provider, and am extremely excited to > be able to dynamically observe various JVM events (especially garbage > collection). Adam and Jarod''s presentation at JavaOne mentions that > there is some performance impact when the DVM probes aren''t enabled, but > I can''t seem to find any data to quantify this. Has anyone by any chance > measured the performance impact of the DVM provider? Is anyone using the > DVM provider in production? >So I bet you are wondering why there is no response to this. The answer is pretty simple - the probe-effect when not actively being DTrace''d is substantial. We are all too embarrassed to quantify it ;) Actually, I finally got the cycles to get back to this and make some improvements. I chatted with Kelly O''Hair yesterday after sending him my diffs and he very quickly turned it around and it is available for your downloading pleasure (https://solaris10-dtrace-vm-agents.dev.java.net/). He posted some comments about the changes so I won''t duplicate that here. For my simple test case of a million method calls and allocations, here are my timing numbers (these are runtimes): No DVM TI agent: 0.451 seconds Original DVM TI agent: 13.624 seconds *NEW* DVM TI agent: 5.091 seconds So that is a bit better. Today, I decided to get really hacky and make it "sorta" dynamic to turn DVM on and off. So that same test above runs in 0.502 seconds with DVM, but not enabled (the DTRACE_PROBE?()''s won''t fire). Then you can flip it on and off just when you need to actually debug something. The probe-effect will be the exact same as the new version when enabled. Kelley has those changes and he can determine if it is a safe and supportable way of doing it (since he is technically the owner). If he likes them, expect another version soon. I only did this for the JVMTI version. However, I still would not recommend using this in production unless you just really had to. Hold out for Mustang if you want something like this in production. Thanks, Jarod
Matty''s email at 2/18/2006 12:57 PM, said:> > Howdy, > > I have been playing with the DVM provider, and am extremely excited to > be able to dynamically observe various JVM events (especially garbage > collection). Adam and Jarod''s presentation at JavaOne mentions that > there is some performance impact when the DVM probes aren''t enabled, but > I can''t seem to find any data to quantify this. Has anyone by any chance > measured the performance impact of the DVM provider? Is anyone using the > DVM provider in production? > > Thanks for any insight, > - Ryan > -- > UNIX Administrator > http://daemons.net/~mattyOkay, now I feel a bit better about answering this question (at least for JVM TI). Go grab the latest bundle - https://solaris10-dtrace-vm-agents.dev.java.net/ - and give it a shot. It ain''t pretty, but at least it came to the dance (sorry, in proper English now (at least for Texans) - It is a complete and total hack, but should address a *major* portion of the non-enabled overhead). Take a look at the README for details on usage and let us know if it makes the DVM provider more approachable. In my tests, it has proven quite effective. If anyone wants to know why I went the pipe route - it is a long story. Short of it is that it makes security, simplicity, and principle of least-surprise sense (actually, I have a better way, but it violates the simplicity clause). That is, one must create the communication channel outside of the control of the VM, least amount of code to write/traverse, and no surprising new ports being listened on by your Java process. Comments are welcome - here or on the DVM discussion page. Thanks, Jarod