harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: Write a graphical front-end for Harmony memory management
Date Sat, 29 Mar 2008 11:49:48 GMT
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 <xiaofeng.li@gmail.com> wrote:
>
> On Mon, Mar 17, 2008 at 3:54 PM, Endre StĂžlsvik <Endre@stolsvik.com> 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

Mime
View raw message