harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paty Lustosa" <patlust...@gmail.com>
Subject Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Date Sun, 13 Apr 2008 17:50:15 GMT
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.



On Sat, Apr 12, 2008 at 7:53 AM, Rick Walker <sky@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message