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
