I spend half my time trying to identify what performance systems are doing by reproducing their behaviour in a performance testbed. It isn't always successful - I'd like to get profile information directly from the production systems, but even low overhead profilers can't get certain types of information in a low enough overhead way (I've tried, believe me I've tried).
One piece of info that is really useful to know is how many of each type of object has been created and has been GC'ed by the JVM. That information isn't available from the JVM, except if you use a profiler (with the honorable exception of JRockit which I think will give you this info in a low overhead way).
But all it takes is two instance variables added to each class object: countCreated and countGCed. And then the JVM just needs to increment each counter for each class when an object is created or GCed. That must surely be a neglible overhead added to the cost of object creation and garbage collection.
This is really the biggest bang for your buck I can think of to add to the JVM for improved monitoring of the system. With that information, so many things become possible, including automatic detection of memory leaks, identification of what may be causing high GC loads, etc.
Gads. Does this guy have any idea how many instances of an object could get created in a normal application? Remove your hands from the code browser, and return your seat to the full and upright position....
Previous Topic
