Alexei Zakharov wrote:
Well, when I was speaking about reusing this console I didn't mean we
should limit ourselves with java.lang.management. This type of
consoles can be used as a graphical UI for everything that is
JMX-compliant. For example JRockit VM exposes its own set of mbeans
(special java control objects) besides standard java.lang.management -
see [1]. Nothing prevents us from doing the same - we could expose
Harmony-specific mbeans that provide desired level of control. The
idea here is just to use standard-based approach (JMX is something
like a standard for exposing management interfaces) and save our
efforts by reusing UI-specific code. Of course, the console itself
could/should be extended to allow the defragmenter-like animation
you've talked about and other nice-looking stuff.
In other words, instead of communicating with GC directly via custom
protocol I suggest writing an additional layer and make our GC
control interface JMX-compliant. In this case it should be manageable
by any JMX-compliant tool. I also can suggest to take a look at
JRockit Mission Control [2] that is a part of JRockit VM distribution.
This is a good example of how JMX-compliant management application
should look like. BTW it has several memory and GC-specific management
controls (custom-made, not part of java.lang.management), memory leak
detector and other good stuff.
[1] http://edocs.beasys.com/jrockit/releases/5026x/javadoc/jlmext/docs/
[2] http://dev2dev.bea.com/pub/a/2005/12/jrockit-mission-control.html
Just to add my +1 to Alexei's comments. Writing custom mbeans is the
right way to go rather than a full custom protocol.
Regards,
Tim
