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