Hello, I've create the wiki page for Google Summer of Code at:
http://wiki.apache.org/harmony/Google_Summer_Of_Code_2008_Projects_Proposals

I put some project proposals there as well.

Thanks,
xiaofeng

On Sun, Mar 2, 2008 at 5:42 PM, Apache Wiki <[EMAIL PROTECTED]> wrote:
> Dear Wiki user,
>
>  You have subscribed to a wiki page or wiki category on "Harmony Wiki" for 
> change notification.
>
>  The following page has been changed by XiaoFeng Li:
>  http://wiki.apache.org/harmony/Google_Summer_Of_Code_2008_Projects_Proposals
>
>  New page:
>  #format wiki
>  #language en
>  (Please add your proposals in the list)
>  == Google Summer Of Code 2008 Projects Proposals ==
>  1. '''Implement the "Compressor" GC proposed by Kermany and Petrank'''.[[BR]]
>  The Compressor garbage collector [1] is a compacting GC that leverages 
> virtual memory support in underlying OS. It compacts the heap in two passes. 
> [[BR]]
>  [1] Haim Kermany, Erez Petrank: ''The Compressor: concurrent, incremental, 
> and parallel compaction''. PLDI 2006.
>
>  2. '''Implement the "Mapping Collector" proposed by Wegiel and 
> Krintz'''.[[BR]]
>  The Mapping Collector [2] utilizes the virtual memory support in a novel way 
> so that it can compact the heap without moving the objects or fixing the 
> references.[[BR]]
>  [2] Michal Wegiel and Chandra Krintz, ''The Mapping Collector: Virtual 
> Memory Support for Generational, Parallel, and Concurrent Compaction'', 
> ASPLOS 2008.
>
>  3. '''Write a graphic font-end for Harmony memory management'''.[[BR]]
>  Harmony runtime needs a graphic front-end visualizing the memory management 
> activities and the runtime status. It can be standalone or better an Eclipse 
> plugin. It can be online display of the runtime execution, or offline 
> processing of the log.
>
>  4. '''Unify the native memory management of Harmony DRLVM'''.[[BR]]
>  DRLVM uses inconsistent APIs for native memory management, such as APR or 
> malloc or mmap. It is desirable to have a unified API for native memory 
> management. Hopefully the runtime native memory usage can be managed with a 
> global view and then optimized. This layer could be extended to provide the 
> API for Java heap native management as well.
>



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

Reply via email to