harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-1900) [DRLVM][GC] patch to enable GCv5 work in non-generational mode
Date Wed, 18 Oct 2006 07:04:35 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-1900?page=comments#action_12443189 ] 
Mikhail Fursov commented on HARMONY-1900:

Just a proposal: why to modify sources to switch GC mode? Does it affect performance?
I would rather use cmd-line options to do it. 

> [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
> 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


View raw message