The industry seems so obsessed with delivering many disjointed management consoles for each element of an application/runtime stack. No thought is given to an unified set of models and interfaces for data collection that is efficient, extensible and versatile.

Looking beneath these consoles one quickly realizes that it is all lip stick on a pig (and people seem to buy porkies). Whereas we first design the model, then the Open API, then build one or more instrumentation integrations, and finally create the visualizations within the console.

I’m sorry if you thought I was trying to get you to divulge your secrets. That was absolutely *not* my intent, though in retrospect I suppose I did push you pretty hard for more information.

You naturally have a lot more background information about your technology, its history, and its successes, than appears in these articles whereas I can only interpret what you’ve written here and ask (hopefully not too impertinent) questions when I don’t see the evidence for some of the statements you make.

I don’t know you, so I don’t know your reputation. I hope no slight was taken because none was intended. I had questions when I read your articles, so I asked them. I did freely admit that the last one in particular was on the aggressive side .

Best of success to you and your company.

Its terribly unfortunate we cannot make publicly available the documentation highlighting this because of one or two companies who systematically clone our innovation and product feature set. But this has its benefits in that the customers we have partnered with have pretty smart people who see beyond the passion we have for our work.

What exactly is your intent?

I have a reputation in the industry for not putting out BS and delivering the goods when all others have failed. I value this. If I say we are the fastest we are the fastest. When this is not the case I will correct this – by making us the fastest once again (I love a good challenge). If that is not good enough for you then so be it. Its not like I am trying to sell to you and even so I would expect you to benchmark us against all other vendors you are considering.

The cost of a metered probe ranges between 250-350 nanoseconds on pretty standard Intel hardware. The largest element of this is the cost in accessing the underlying meter counter (or counters). The rest is related to the update of metering associated with one or more metering cost groups represented by a composite probe name.

We do have meters (counters) specific to the Azul hardware which points to our extensibility of our metering runtime.

The primary overhead for a probe is not in the firing but in the metering which consists of two parts – meter access time and aggregated metering update. Probes in JXInsight are associated with dynamic metering strategies that determine whether an actually firing results in a metering. We have a large number of strategies available via a simple system property and customers can combine them together to make even more exotic metering strategies to suit the execution nature of the application being monitored. Hotspot is our default one and it basically does what the JVM hotspot engine does but naturally from a metering perspective.

Some answers that might help understand this statement: Is the overhead higher for a hotspot method? On what kind of machine, running with kind of application, probing what kind of information, with what level of accuracy, over what period of time, etc.

It’s an aggressively framed posting, I admit, but then again: the statement is virtually information free linking to an also information free link as supporting evidence for the statement! I am not necessarily disputing your statement, I’m saying it’s impossible to interpret it without more information.

Another thing I’m confused about is whether this tool is something Azul-specific or if it runs as efficiently on off-the-shelf systems?

http://williamlouth.wordpress.com/2009/01/07/profiling-sampling-versus-execution-part-1/

http://williamlouth.wordpress.com/2009/01/16/profiling-sampling-versus-execution-part-2/

http://williamlouth.wordpress.com/2009/07/27/one-billion-operations-per-second/

That said it [Visual VM] is likely to end up looking like another Eclipse frankenstein tool as you have focused wrongly (IMHO) on the console rather than the underlying data models. But that is easy to say with experience.

Detailed memory profiling should be used during development & testing and tools like Visual VM, Yourkit, Eclipse MAT, and NetBeans Profiler are good choices here. All these tools are more than adequate for focused code tuning. For both software and system execution behavior analysis under production workload levels then there is currently only one viable solution at least from my benchmarking and feature comparison – JXInsight.