United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4619006 RFE: MBeanServerImpl should use caching in invoke()
JDK-4619006 : RFE: MBeanServerImpl should use caching in invoke()

Details
Type:
Enhancement
Submit Date:
2002-01-03
Status:
Resolved
Updated Date:
2005-09-17
Project Name:
JDK
Resolved Date:
2005-09-17
Component:
core-svc
OS:
generic
Sub-Component:
javax.management
CPU:
generic
Priority:
P5
Resolution:
Fixed
Affected Versions:
2.0
Fixed Versions:

Related Reports

Sub Tasks

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

                                    

Comments
PUBLIC COMMENTS

.
                                     
2004-09-01
EVALUATION

###@###.### 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.
                                     
2004-09-01
EVALUATION

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.
                                     
2005-09-09



Hardware and Software, Engineered to Work Together