harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Write a graphical front-end for Harmony memory management
Date Thu, 03 Apr 2008 09:25:59 GMT
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.


View raw message