Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: commits@harmony.apache.org
Date: Sun, 02 Mar 2008 09:42:02 -0000
Message-ID: <20080302094202.892.66496@eos.apache.org>
Subject: [Harmony Wiki] Update of "Google Summer Of Code 2008 Projects
 Proposals" by
 XiaoFeng Li

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.