harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: Write a graphical front-end for Harmony memory management
Date Thu, 03 Apr 2008 14:17:15 GMT
On Thu, Apr 3, 2008 at 5:25 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 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.

I guess they are probably two complementary things. In my
understanding, MBeans do not define the exact GC profiling protocol,
which is GCspy's focus. MBeans can be used to implement the similar
protocol. For this project, my original idea was to have two steps,
first is to connect GCspy with Harmony to understand the protocol and
the issues there, second is to have an Eclipse plugin for Harmony. It
depends on the student's experience/capability for the second step. I
am ok if the student chooses JMX. Thanks.


>  Regards,
>  Tim


View raw message