harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Date Mon, 14 Apr 2008 00:21:33 GMT
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 <patlustosa@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 <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
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message