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 <[EMAIL PROTECTED]> 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 <[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 > -- * Patrícia Lustosa Ventura Ribeiro * Ciências da Computação - 2005.1 AJaTS - AspectJ Transformation System
