harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: Write a graphical front-end for Harmony memory management
Date Mon, 07 Apr 2008 08:34:04 GMT
Ok, sounds good. My only point here is just to be sure we aren't
reinventing the wheel. BTW, what is the protocol that GCSpy uses for
connecting to VMs? Does it have something to do with JVMTI? I've tried
to find a quick answer by browsing their site but didn't find much.

Thanks,
Alexei

2008/4/3, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> 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.
>
>  Thanks,
>  xiaofeng
>
>  >  Regards,
>  >  Tim
>  >
>
>
>
>
>  --
>
> http://xiao-feng.blogspot.com
>

Mime
View raw message