You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Rick Walker <ri...@gmail.com> on 2008/04/02 14:25:39 UTC
[GSoC2008] Write a graphical front-end for Harmony memory management
Hi,
I've been corresponding with Xiao-Feng off-list about this GSoC
proposal, and he suggested that it'd be useful to invite comments from
the wider Harmony community.
My proposal as it stands is at:
http://wiki.apache.org/general/RickWalker/GSoC2008/harmony-gc-3
and, in summary, proposes integrating GCSpy into Harmony for
visualization. I met last week with Richard Jones[1] (also at the
University of Kent) to discuss this, and, since he's mentoring a
similar project for Jikes, he's indicated that he'll be available for
support over the summer period.
Any comments or feedback to help improve my proposal would be most welcome.
Thanks,
Rick
[1] http://www.cs.kent.ac.uk/~rej
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Paty Lustosa <pa...@gmail.com>.
Xia-Feng,
I have already used TPTP testing project, to test some Eclipse plug-in's
that I developed. The others TPTP subprojects I have never used before.
Thanks,
Paty
On Sun, Apr 13, 2008 at 9:21 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
> Paty, are you familiar with Eclipse TPTP? I am not sure how difficult
> it is to reuse TPTP framework to visualize JVM internals. So I cc
> Vasily for his opinions.
>
> Thanks,
> xiaofeng
>
> On Mon, Apr 14, 2008 at 1:50 AM, Paty Lustosa <pa...@gmail.com>
> wrote:
> > Hi Rick,
> >
> > Xiao-Feng told me that he didn't intend to use TuningFork due to
> unclear
> > license. So I think that it's better for me to develop a GCSpy client
> as an
> > Eclipse plug-in while you work in the integration of GCSpy with
> Harmony.
> > What do you think about it, Xiao-Feng?
> > Any comments are welcome.
> >
> > Thanks,
> >
> > Patrícia
> >
> >
> >
> > On Sat, Apr 12, 2008 at 7:53 AM, Rick Walker <sk...@nildram.co.uk> wrote:
> >
> > > Hi Patrícia,
> > >
> > > In my proposal, I elected just to integrate GCSpy with Harmony - I
> had
> > > a chat with Richard Jones at Kent, who's responsible for GCSpy and
> has
> > > a similar GSoC project running for JikesRVM, and discussed exactly
> how
> > > far he thought I could get with it over the GSoC period. The
> > > conclusions we came to from that discussion was that integrating
> > > GCSpy, writing drivers for each GC, and then updating GCSpy itself to
> > > include the latest changes made to the architecture
> > > (http://pubs.doc.ic.ac.uk/GCspy/ has some information on that) was
> > > possible. It's likely that the latter part would benefit from
> > > communication with the JikesRVM project, to make sure that the GCSpy
> > > servers (C++ for Harmony, Java for JikesRVM) are consistent.
> > >
> > > Richard also stressed that it's very important that GCSpy have
> > > negligible performance impact when the visualizer's not connected,
> and
> > > suggested ways I could benchmark to check that this is the case.
> > > I think that it's realistic to integrate GCSpy and test it properly
> > > over the GSoC period, and I wrote up my proposal based on that, from
> a
> > > deliverable-oriented perspective. While I'd definitely be interested
> > > in longer-term involvement with Harmony if this summer goes to plan,
> I
> > > felt that this was a sensible way to approach GSoC.
> > >
> > > I didn't, then, look too deeply at writing Eclipse plugins, though I
> > > did have a brief scan of the Rich Client Platform documentation. The
> > > proposal I looked at from Jikes:
> > > http://jira.codehaus.org/browse/RVM-388
> > > discusses the possibility of adding GCSpy-style visualization to
> Tuning
> > > Fork:
> > > http://www.alphaworks.ibm.com/tech/tuningfork
> > >
> > >
> http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.tenedor.html
> > > (has a link to their research paper on it too). You could extend
> > > tuning fork to support GCSpy-style visualizations as a plugin. The
> > > only problem is that while I think Tuning Fork's going to be released
> > > as OSS, it isn't at the moment.
> > >
> > > Perhaps a split of integrating GCSpy with Harmony vs developing a
> > > better client as an eclipse plug in could work? I'm sure there are
> > > other interesting ways of visualizing GC trace output, so there's
> > > enough depth on that side too.
> > >
> > > Rick
> > >
> >
> >
> >
> >
> >
> > --
> > * Patrícia Lustosa Ventura Ribeiro *
> > Ciências da Computação - 2005.1
> > AJaTS - AspectJ Transformation System
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--
* Patrícia Lustosa Ventura Ribeiro *
Ciências da Computação - 2005.1
AJaTS - AspectJ Transformation System
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Xiao-Feng Li <xi...@gmail.com>.
Paty, are you familiar with Eclipse TPTP? I am not sure how difficult
it is to reuse TPTP framework to visualize JVM internals. So I cc
Vasily for his opinions.
Thanks,
xiaofeng
On Mon, Apr 14, 2008 at 1:50 AM, Paty Lustosa <pa...@gmail.com> wrote:
> Hi Rick,
>
> Xiao-Feng told me that he didn't intend to use TuningFork due to unclear
> license. So I think that it's better for me to develop a GCSpy client as an
> Eclipse plug-in while you work in the integration of GCSpy with Harmony.
> What do you think about it, Xiao-Feng?
> Any comments are welcome.
>
> Thanks,
>
> Patrícia
>
>
>
> On Sat, Apr 12, 2008 at 7:53 AM, Rick Walker <sk...@nildram.co.uk> wrote:
>
> > Hi Patrícia,
> >
> > In my proposal, I elected just to integrate GCSpy with Harmony - I had
> > a chat with Richard Jones at Kent, who's responsible for GCSpy and has
> > a similar GSoC project running for JikesRVM, and discussed exactly how
> > far he thought I could get with it over the GSoC period. The
> > conclusions we came to from that discussion was that integrating
> > GCSpy, writing drivers for each GC, and then updating GCSpy itself to
> > include the latest changes made to the architecture
> > (http://pubs.doc.ic.ac.uk/GCspy/ has some information on that) was
> > possible. It's likely that the latter part would benefit from
> > communication with the JikesRVM project, to make sure that the GCSpy
> > servers (C++ for Harmony, Java for JikesRVM) are consistent.
> >
> > Richard also stressed that it's very important that GCSpy have
> > negligible performance impact when the visualizer's not connected, and
> > suggested ways I could benchmark to check that this is the case.
> > I think that it's realistic to integrate GCSpy and test it properly
> > over the GSoC period, and I wrote up my proposal based on that, from a
> > deliverable-oriented perspective. While I'd definitely be interested
> > in longer-term involvement with Harmony if this summer goes to plan, I
> > felt that this was a sensible way to approach GSoC.
> >
> > I didn't, then, look too deeply at writing Eclipse plugins, though I
> > did have a brief scan of the Rich Client Platform documentation. The
> > proposal I looked at from Jikes:
> > http://jira.codehaus.org/browse/RVM-388
> > discusses the possibility of adding GCSpy-style visualization to Tuning
> > Fork:
> > http://www.alphaworks.ibm.com/tech/tuningfork
> >
> > http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.tenedor.html
> > (has a link to their research paper on it too). You could extend
> > tuning fork to support GCSpy-style visualizations as a plugin. The
> > only problem is that while I think Tuning Fork's going to be released
> > as OSS, it isn't at the moment.
> >
> > Perhaps a split of integrating GCSpy with Harmony vs developing a
> > better client as an eclipse plug in could work? I'm sure there are
> > other interesting ways of visualizing GC trace output, so there's
> > enough depth on that side too.
> >
> > Rick
> >
>
>
>
>
>
> --
> * Patrícia Lustosa Ventura Ribeiro *
> Ciências da Computação - 2005.1
> AJaTS - AspectJ Transformation System
>
--
http://xiao-feng.blogspot.com
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Ian Rogers <ro...@gmail.com>.
Paty Lustosa wrote:
> Hi Rick,
>
> Xiao-Feng told me that he didn't intend to use TuningFork due to unclear
> license. So I think that it's better for me to develop a GCSpy client as an
> Eclipse plug-in while you work in the integration of GCSpy with Harmony.
> What do you think about it, Xiao-Feng?
> Any comments are welcome.
>
> Thanks,
>
> Patrícia
>
Hi,
just to follow this up. Tuning fork has now been released under the
Eclipse Public License:
http://tuningforkvp.sourceforge.net/
There is a related Jikes RVM issue:
http://jira.codehaus.org/browse/RVM-507
Regards,
Ian
> On Sat, Apr 12, 2008 at 7:53 AM, Rick Walker <sk...@nildram.co.uk> wrote:
>
>
>> Hi Patrícia,
>>
>> In my proposal, I elected just to integrate GCSpy with Harmony - I had
>> a chat with Richard Jones at Kent, who's responsible for GCSpy and has
>> a similar GSoC project running for JikesRVM, and discussed exactly how
>> far he thought I could get with it over the GSoC period. The
>> conclusions we came to from that discussion was that integrating
>> GCSpy, writing drivers for each GC, and then updating GCSpy itself to
>> include the latest changes made to the architecture
>> (http://pubs.doc.ic.ac.uk/GCspy/ has some information on that) was
>> possible. It's likely that the latter part would benefit from
>> communication with the JikesRVM project, to make sure that the GCSpy
>> servers (C++ for Harmony, Java for JikesRVM) are consistent.
>>
>> Richard also stressed that it's very important that GCSpy have
>> negligible performance impact when the visualizer's not connected, and
>> suggested ways I could benchmark to check that this is the case.
>> I think that it's realistic to integrate GCSpy and test it properly
>> over the GSoC period, and I wrote up my proposal based on that, from a
>> deliverable-oriented perspective. While I'd definitely be interested
>> in longer-term involvement with Harmony if this summer goes to plan, I
>> felt that this was a sensible way to approach GSoC.
>>
>> I didn't, then, look too deeply at writing Eclipse plugins, though I
>> did have a brief scan of the Rich Client Platform documentation. The
>> proposal I looked at from Jikes:
>> http://jira.codehaus.org/browse/RVM-388
>> discusses the possibility of adding GCSpy-style visualization to Tuning
>> Fork:
>> http://www.alphaworks.ibm.com/tech/tuningfork
>>
>> http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.tenedor.html
>> (has a link to their research paper on it too). You could extend
>> tuning fork to support GCSpy-style visualizations as a plugin. The
>> only problem is that while I think Tuning Fork's going to be released
>> as OSS, it isn't at the moment.
>>
>> Perhaps a split of integrating GCSpy with Harmony vs developing a
>> better client as an eclipse plug in could work? I'm sure there are
>> other interesting ways of visualizing GC trace output, so there's
>> enough depth on that side too.
>>
>> Rick
>>
>>
>
>
>
>
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Paty Lustosa <pa...@gmail.com>.
Hi Rick,
Xiao-Feng told me that he didn't intend to use TuningFork due to unclear
license. So I think that it's better for me to develop a GCSpy client as an
Eclipse plug-in while you work in the integration of GCSpy with Harmony.
What do you think about it, Xiao-Feng?
Any comments are welcome.
Thanks,
Patrícia
On Sat, Apr 12, 2008 at 7:53 AM, Rick Walker <sk...@nildram.co.uk> wrote:
> Hi Patrícia,
>
> In my proposal, I elected just to integrate GCSpy with Harmony - I had
> a chat with Richard Jones at Kent, who's responsible for GCSpy and has
> a similar GSoC project running for JikesRVM, and discussed exactly how
> far he thought I could get with it over the GSoC period. The
> conclusions we came to from that discussion was that integrating
> GCSpy, writing drivers for each GC, and then updating GCSpy itself to
> include the latest changes made to the architecture
> (http://pubs.doc.ic.ac.uk/GCspy/ has some information on that) was
> possible. It's likely that the latter part would benefit from
> communication with the JikesRVM project, to make sure that the GCSpy
> servers (C++ for Harmony, Java for JikesRVM) are consistent.
>
> Richard also stressed that it's very important that GCSpy have
> negligible performance impact when the visualizer's not connected, and
> suggested ways I could benchmark to check that this is the case.
> I think that it's realistic to integrate GCSpy and test it properly
> over the GSoC period, and I wrote up my proposal based on that, from a
> deliverable-oriented perspective. While I'd definitely be interested
> in longer-term involvement with Harmony if this summer goes to plan, I
> felt that this was a sensible way to approach GSoC.
>
> I didn't, then, look too deeply at writing Eclipse plugins, though I
> did have a brief scan of the Rich Client Platform documentation. The
> proposal I looked at from Jikes:
> http://jira.codehaus.org/browse/RVM-388
> discusses the possibility of adding GCSpy-style visualization to Tuning
> Fork:
> http://www.alphaworks.ibm.com/tech/tuningfork
>
> http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.tenedor.html
> (has a link to their research paper on it too). You could extend
> tuning fork to support GCSpy-style visualizations as a plugin. The
> only problem is that while I think Tuning Fork's going to be released
> as OSS, it isn't at the moment.
>
> Perhaps a split of integrating GCSpy with Harmony vs developing a
> better client as an eclipse plug in could work? I'm sure there are
> other interesting ways of visualizing GC trace output, so there's
> enough depth on that side too.
>
> Rick
>
--
* Patrícia Lustosa Ventura Ribeiro *
Ciências da Computação - 2005.1
AJaTS - AspectJ Transformation System
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Rick Walker <sk...@nildram.co.uk>.
Hi Patrícia,
In my proposal, I elected just to integrate GCSpy with Harmony - I had
a chat with Richard Jones at Kent, who's responsible for GCSpy and has
a similar GSoC project running for JikesRVM, and discussed exactly how
far he thought I could get with it over the GSoC period. The
conclusions we came to from that discussion was that integrating
GCSpy, writing drivers for each GC, and then updating GCSpy itself to
include the latest changes made to the architecture
(http://pubs.doc.ic.ac.uk/GCspy/ has some information on that) was
possible. It's likely that the latter part would benefit from
communication with the JikesRVM project, to make sure that the GCSpy
servers (C++ for Harmony, Java for JikesRVM) are consistent.
Richard also stressed that it's very important that GCSpy have
negligible performance impact when the visualizer's not connected, and
suggested ways I could benchmark to check that this is the case.
I think that it's realistic to integrate GCSpy and test it properly
over the GSoC period, and I wrote up my proposal based on that, from a
deliverable-oriented perspective. While I'd definitely be interested
in longer-term involvement with Harmony if this summer goes to plan, I
felt that this was a sensible way to approach GSoC.
I didn't, then, look too deeply at writing Eclipse plugins, though I
did have a brief scan of the Rich Client Platform documentation. The
proposal I looked at from Jikes:
http://jira.codehaus.org/browse/RVM-388
discusses the possibility of adding GCSpy-style visualization to Tuning Fork:
http://www.alphaworks.ibm.com/tech/tuningfork
http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.tenedor.html
(has a link to their research paper on it too). You could extend
tuning fork to support GCSpy-style visualizations as a plugin. The
only problem is that while I think Tuning Fork's going to be released
as OSS, it isn't at the moment.
Perhaps a split of integrating GCSpy with Harmony vs developing a
better client as an eclipse plug in could work? I'm sure there are
other interesting ways of visualizing GC trace output, so there's
enough depth on that side too.
Rick
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Paty Lustosa <pa...@gmail.com>.
Hi Rick,
I also have been corresponding with Xiao-Feng about this project and I also
proposed to it (Write a graphical front-end for Harmony memory management).
Xiao told me to discuss the proposal with you to see if we can come up with
two different proposals with enough substances. In my proposal, I present
two objectives:
1. GCspy integration
GCspy is a heap visualization framework that allows developers to observe
the behavior of the heap and related data structures. GCspy adopted a
client-server architecture. The system being visualized, Harmony, is the
server. In order to integrate GCspy with Harmony, I am going to write a
GCspy driver for each of its GC algorithms. A driver is a module that maps
the operation and layout of an algorithm onto the generic GCspy
abstractions. With this, Harmony will have its standalone visualization
tool.
2. Eclipse plug-in
There are two options to this part of the project. I could simplify GCspy
and modify it to be an Eclipse[3] plug-in. The second option is to rewrite
my own visualization tool. The decision is going to be made with the mentor
depending on the time available and the experience got in the first step.
What do you think? In your proposal, you considere the GCSpy integration
only or something else too?
Thanks,
Patrícia Lustosa
On Wed, Apr 2, 2008 at 9:20 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
> Rick, your proposal looks good. At the moment I have no further
> comments. Thanks. -xiaofeng
>
> On Wed, Apr 2, 2008 at 8:25 PM, Rick Walker <ri...@gmail.com>
> wrote:
> > Hi,
> >
> > I've been corresponding with Xiao-Feng off-list about this GSoC
> > proposal, and he suggested that it'd be useful to invite comments from
> > the wider Harmony community.
> >
> > My proposal as it stands is at:
> >
> > http://wiki.apache.org/general/RickWalker/GSoC2008/harmony-gc-3
> >
> > and, in summary, proposes integrating GCSpy into Harmony for
> > visualization. I met last week with Richard Jones[1] (also at the
> > University of Kent) to discuss this, and, since he's mentoring a
> > similar project for Jikes, he's indicated that he'll be available for
> > support over the summer period.
> >
> > Any comments or feedback to help improve my proposal would be most
> welcome.
> >
> > Thanks,
> >
> > Rick
> >
> > [1] http://www.cs.kent.ac.uk/~rej
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--
* Patrícia Lustosa Ventura Ribeiro *
Ciências da Computação - 2005.1
AJaTS - AspectJ Transformation System
Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Posted by Xiao-Feng Li <xi...@gmail.com>.
Rick, your proposal looks good. At the moment I have no further
comments. Thanks. -xiaofeng
On Wed, Apr 2, 2008 at 8:25 PM, Rick Walker <ri...@gmail.com> wrote:
> Hi,
>
> I've been corresponding with Xiao-Feng off-list about this GSoC
> proposal, and he suggested that it'd be useful to invite comments from
> the wider Harmony community.
>
> My proposal as it stands is at:
>
> http://wiki.apache.org/general/RickWalker/GSoC2008/harmony-gc-3
>
> and, in summary, proposes integrating GCSpy into Harmony for
> visualization. I met last week with Richard Jones[1] (also at the
> University of Kent) to discuss this, and, since he's mentoring a
> similar project for Jikes, he's indicated that he'll be available for
> support over the summer period.
>
> Any comments or feedback to help improve my proposal would be most welcome.
>
> Thanks,
>
> Rick
>
> [1] http://www.cs.kent.ac.uk/~rej
>
--
http://xiao-feng.blogspot.com