On Mon, Apr 7, 2008 at 4:34 PM, Alexei Zakharov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > On Thu, Apr 3, 2008 at 5:25 PM, Tim Ellison <[EMAIL PROTECTED]> 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
