You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "weldon washburn (JIRA)" <ji...@apache.org> on 2006/10/18 17:36:36 UTC
[jira] Assigned: (HARMONY-1900) [DRLVM][GC] patch to enable GCv5
work in non-generational mode
[ http://issues.apache.org/jira/browse/HARMONY-1900?page=all ]
weldon washburn reassigned HARMONY-1900:
----------------------------------------
Assignee: weldon washburn
> [DRLVM][GC] patch to enable GCv5 work in non-generational mode
> --------------------------------------------------------------
>
> Key: HARMONY-1900
> URL: http://issues.apache.org/jira/browse/HARMONY-1900
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: Windows VS.net 2003, and Linux FC4
> Reporter: Xiao-Feng Li
> Assigned To: weldon washburn
> Attachments: 01-gcv5-nowb-unix.patch
>
>
> This patch has made a couple of big improvements:
> 1. It can work in non-generational mode. To enable it, edit file gen/gc_for_barrier.cpp to change the NEED_BARRIER to FALSE. This feature can help to debug and test GC correctness with and without write barriers, and it also helps to verify the modular design. The algorithm of the non-gen mode is copy-compaction: every minor collection copies live objects from nursery space to mature space, and a major collection will slide compact the whole heap.
> 2. Unified the heap data structure of NOS (nursery obj space) and MOS (mature obj space) to use the same blocked orgnization. This helps to simplify the design with uniform processing for both NOS and MOS blocks, and it also helps the major collection where NOS and MOS are handled together.
> 3. Removed the object remembering sets in write barrier. It is not needed at the moment and will be added later when needed. The obj remembering mechanism needs reconsidering when it's time to cleanup the write barrier interface. The current interface in GC for write barrier is legacy that will evolve gradually along with GCv5 progress. The removal also prepares for the marking phase parallelization which is not in the code but under consideration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira