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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
