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 Mon, 07 Apr 2008 08:43:07 GMT
On Mon, Apr 7, 2008 at 4:34 PM, Alexei Zakharov
<alexei.zakharov@gmail.com> wrote:
> 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.
>

It uses custom protocol, not JVMTI. JVMTI alone is not enough unless
be extended for heap management. GCspy work in this project could be a
good reference for the extension. TPTP has some experience.

Thanks,
xiaofeng

>  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
>  >
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message