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 Regards, Alexei 2008/4/3, Xiao-Feng Li <[EMAIL PROTECTED]>: > On Wed, Apr 2, 2008 at 7:24 PM, Alexei Zakharov > > <[EMAIL PROTECTED]> wrote: > > > Hi Xiao-Feng, > > > > AFAIK it's just a general-purpose JMX console with SWT front end. I.e. > > it can manage everything that exposes JMX-compliant interface. IIRC I > > successfully tested it with Bea Weblogic J2EE server and Bea JRockit > > JVM. BTW, to be able to manage JVM internal resources you'll need to > > enable its management agent for local monitoring: "-Xmanagement" on > > JRockit and "-Dcom.sun.management.jmxremote" on Sun. I'm not sure if > > we have something like it in Harmony. These agents just provide the > > access to mbeans from "java.lang.management" package. So its > > management interface is limited to the functionality provided by > > java.lang.management. Sun also has management console called jconsole > > - see [1]. JRockit has JRockit Management Console. > > > > [1] http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html > > > Ok, thanks. Looks like it's not directly applicable to the project. > java.lang.management is not so specific to GC internals. It has a few > interfaces for memory management, which are too high-level to expose > GC internals. On the other hand, TPTP could be a good reference. > > Thanks, > xiaofeng > > > > Regards, > > Alexei > > > > 2008/4/2, Xiao-Feng Li <[EMAIL PROTECTED]>: > > > > > > > On Mon, Mar 31, 2008 at 1:34 PM, Alexei Zakharov > > > <[EMAIL PROTECTED]> wrote: > > > > BTW I just like pay everybody's attention on HARMONY-1105 [1]. It is > a > > > > Java management console implemented as an eclipse plugin; donated to > > > > Harmony on Aug 2006. May be it can be (re)used somehow for memory > > > > management purposes too. > > > > > > > > [1] http://issues.apache.org/jira/browse/HARMONY-1105 > > > > > > > > > Alexei, thanks for the suggestion. I need more understandings about the > console: > > > 1. Which component does it work with in Harmony? I'd like to see check > > > the features in details. > > > 2. Can it work with GC in low-level details? For example, can it > > > support to show an object is moved from one location to another (as > > > what we saw in Windows defragmentor)? > > > > > > Thanks, > > > xiaofeng > > > > > > > > > > > > > Thanks, > > > > Alexei > > > > > > > > 2008/3/29, Alexei Fedotov <[EMAIL PROTECTED]>: > > > > > > > > > > > > > Let me share few ideas: > > > > > > > > > > > > > > > > Step 1. to make Harmony work with GCspy based on its current > codebase; > > > > > > > > > > > > > > > This is a good work breakdown, but I want to see more in the > > > > > application. I believe the goal of the project should be more > visible > > > > > and somehow reflect the usefulness. I would set the goal to > improve > > > > > memory or performance profile of some application on Harmony > using > > > > > GCspy, or in simpler words, enable GCspy to a degree when it > would be > > > > > able to do something useful. > > > > > > > > > > > > > > > > Step 2. to modify GCspy for our monitoring/tuning needs as an > Eclipse plugin. > > > > > > > > > > > > > > > May be one should think of aligning GCspy and TPTP instead. This > is > > > > > more about supplementing TPTP with missed and useful things from > GCspy > > > > > rather than GCspy porting. While it is useful sometimes and > > > > > unavoidable during hard times, for these two projects I do not > see > > > > > enough arguments why they should compete instead of being merged > into > > > > > something more useful. > > > > > > > > > > I agree with Xiao Feng that each of these tasks might be too > ambitious > > > > > for a student project. > > > > > > > > > > > > > > > On Mon, Mar 17, 2008 at 12:43 PM, Xiao-Feng Li <[EMAIL > PROTECTED]> wrote: > > > > > > > > > > > > On Mon, Mar 17, 2008 at 3:54 PM, Endre Stølsvik <[EMAIL > PROTECTED]> wrote: > > > > > > > Xiao-Feng Li wrote: > > > > > > > > > > > > > > > For this GSoC project, it's probably enough to have the > bullet 1 > > > > > > > > achieved, and GCspy is a very good reference. Well the > wish for bullet > > > > > > > > 1 is to make it self-contained within Harmony as a > plugin of Eclipse > > > > > > > > (i.e., least dependent on external software but Eclipse > related). > > > > > > > > > > > > > > Why wouldn't it be *much* better to integrate the existing > GCSpy project > > > > > > > (which apparently requires a "server" integration in that > JVM to be done > > > > > > > - KVM has e.g. done it), and if it lacks something, code > it into GCSpy > > > > > > > proper code? Then all will benefit.. > > > > > > > > > > > > Endre, thanks for the suggestion. I actually thought the same > thing, I > > > > > > am just not sure if a GSoC project can be that ambitious, > since in my > > > > > > understanding, GCspy is quite well-designed to accommodate > various > > > > > > runtime systems, and it's keep improving. Also I don't know > GCspy's > > > > > > maintenance model. > > > > > > > > > > > > Probably we can partition the tasks into two steps: > > > > > > Step 1. to make Harmony work with GCspy based on its current > codebase; > > > > > > Step 2. to modify GCspy for our monitoring/tuning needs as an > Eclipse plugin. > > > > > > > > > > > > How do you think about them? Thanks. > > > > > > > > > > > > I don't know how Ian wants to roll out his RVM visualization > proposal. > > > > > > Ian, do you plan to enhance GCspy with TuningFork idea or to > migrate > > > > > > RVM to work with the TuningFork framework? > > > > > > > > > > > > Thanks, > > > > > > xiaofeng > > > > > > > > > > > > > Endre. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://xiao-feng.blogspot.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > With best regards, > > > > > > > > > > Alexei > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://xiao-feng.blogspot.com > > > > > > > > > > -- > > http://xiao-feng.blogspot.com >
