In reflection there are two things that needs to be done in order to
invoke a method on an  customer : lookup the method, and invoke it on the
 customer . The latter is fast, the former is slow. Method lookups in
invoke() are not cached, hence seriously impacting the performance of
MBeanServer.invoke().

N/A

  xxxxx@xxxxx   2002-01-04

Not a bad idea, but I am not sure looking up in the cache will be faster than
lookup in the Class, at least for operations.
For attributes, caching the getter/setter is probably a good idea, although
the impact on memory footprint must be kept in mind.

Since the invoke() is now performed by the Metadata, we can imagine to provide
several implementation of MetadataImpl and let the user choose which one
he wishes to use.
Posted Date : 2005-09-01 08:57:18.0

Looking up cached methods is faster even for operations because it avoids having to load each class named in the String[] signature array from MBeanServer.invoke.  This optimization is now implemented with common code for Standard MBeans and MXBeans that finds Method objects in Maps.  For invoke, it is only necessary to compare the received signature array with the signature array of the previously-discovered operation (or operations, in case of overloading).

A simple microbenchmark that calls MBeanServer.getAttribute on a Standard MBean 100000 times in a tight loop (measured after "warming up" the JVM by first repeatedly executing the test code without measuring) shows a reduction from 918 ms to 246 ms, i.e. about 270% faster.
Posted Date : 2005-09-09 13:16:27.0

In the case of "true" standard MBeans and in the case of javax.management.StandardMBean it is critical for our application that the Method objects for attribute getters be cached.  Various dynamic mbean base classes (e.g. MXBean as well in Java 6) should do likewise.

In our case, the lack of such caching is a substantial bottleneck for flexible MBean-attribute-name-based data acquisition (e.g. for frequent logging of user specified attributes from short-lived objects).  Note that for this use case the StandardMBean is generally not even registered with the MBeanServer -- rather DynamicMBean.getAttributes() is used for its flexibility -- and this should not come with an overt performance penalty as it does now.

Note we really need this fixed in a Java 5 update -- otherwise I'll have to write our own StandardMBean class to replace Sun's (using a different package, of course).

I have now written my own replacement for the JRE's standard MBean in an attempt to improve upon this and the lack of MBeanInfo caching based on MBeanInterface (I cache this and then augment based on the implementation prior to augmenting based on the customization hooks).

Based on this I have done some timings.  In my use case, my operation went from 0.09 ms to 0.05 ms.  These times are based on nanoTime() results accumulated over 100,000 executions after 100,000 warmup executions.  Note that the time includes more than just getAttributes(), so the percentage improvement of that portion of the operation is actually larger!  Also note that while these numbers seem small this operation is called a *lot*...