Re: [rvm-research] Google Summer of Code 2011

[Filip P. <pi...@pu...>]

I second that.  It would be great to have these working, so people could 
experiment with more interesting concurrent collection strategies.  The 
implementation itself could lead to a nice paper for the people 
involved, if properly evaluated.

-Filip



On 2/21/2011 4:55 AM, Erez Petrank wrote:
> I think there are three major candidates for concurrent collectors in
> Jikes.
> - The DLG algorithm (originally at POPL'93 and POPL'94, with some IBM
> Java implementation described in [Domani et al. ISMM'00])
> - The Azatchi et al. from OOPSLA 2003
> - The mostly concurrent collector [Boehm et al. 1991, and some IBM
> Java implementation in [Barabash et al. Toplas 2005]
>
> I would think that the mostly-concurrent is the easiest to implement,
> but has a long pause time. (Maybe the least concurrent of them all.)
> The Azatzhi collector has an advantage of having two versions: a
> simple concurrent collector (with a reasonable pause time) and a fully
> on-the-fly collector which is more difficult, but has almost no pause
> time. This collector also has the advantage that it has a structure
> that easily extends to a concurrent reference-counting collector.
>
> It would be great to have those in Jikes.
>
> --Erez
>
>
>
>
> On 18-Feb-11, at 4:48 PM, Tony Hosking wrote:
>
>> I'd like to see another concurrent collector implementation for
>> MMTk.  Last year we got Sapphire mostly done.  Maybe concurrent
>> Immix would be a good target?
>>
>> On Feb 18, 2011, at 5:26 AM, Richard Jones wrote:
>>
>>> Once again, we are hoping to participate in the Google Summer of
>>> Code. We have had some really excellent contributions to JikesRVM
>>> come out of previous Summers of Code so please take the time to
>>> visit the Jikes RVM Google Summer of Code 2011 pages.
>>>
>>> The current set of project proposals is a draft, mainly made up of
>>> proposals from last year. We need new projects and new mentors.
>>> Please offer some.
>>>
>>> The organization application deadline is 11 March.
>>>
>>> Richard
>>> ------------------------------------------------------------------------------
>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel
>>> Studio XE:
>>> Pinpoint memory and threading errors before they happen.
>>> Find and fix more than 250 security defects in the development cycle.
>>> Locate bottlenecks in serial and parallel code that limit
>>> performance.
>>> http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________
>>> Jikesrvm-researchers mailing list
>>> Jik...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel
>> Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________
>> Jikesrvm-researchers mailing list
>> Jik...@li...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers