harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: Write a graphical front-end for Harmony memory management
Date Mon, 31 Mar 2008 05:34:23 GMT
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 <alexei.fedotov@gmail.com>:
> 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