harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <rogers.em...@gmail.com>
Subject Re: [GSoC2008] Write a graphical front-end for Harmony memory management
Date Tue, 20 May 2008 16:00:48 GMT
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 <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
>>
>>     
>
>
>
>   


Mime
View raw message