Humberto, Compacting GC is only used for MOS collection (and probably LOS if applicable). NOS always uses copying GC. But in my opinion, you don't need worry about that at the beginning, you can write a compacting GC that manages the entire heap (probably except for LOS).
To create a new space, please follow the steps in mark-sweep for wspace. And when USE_UNIQUE_MARK_SWEEP_GC, wspace manages the entire heap (including large objects). So it can be a reference for standalone GC without NOS. On the other hand, if you feel it's hard to master the Harmony GC code base, you can create another directory, say gc_compressor/ on par with gc_gen/, to write a standalone compressor without considering how it interacts with the existing GC code base. And you can reuse any part of gc_gen/ if that's useful. Thanks, xiaofeng On Fri, Apr 11, 2008 at 9:33 PM, Humberto Naves <[EMAIL PROTECTED]> wrote: > The Compressor strategy should be used where? NOS? MOS? LOS? > And what are the first step for creating a new "cspace" ? > Many thanks, > Humberto > > > > On Wed, Apr 9, 2008 at 10:51 PM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > On Thu, Apr 10, 2008 at 4:57 AM, Humberto Naves <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I have a few questions about the Compressor GC that should be > > implemented in > > > Harmony DRLVM: > > > -> What strategy will we use for constructing the "markbit" vector? > > > (Pool-sharing parallelization?) > > > > It can be done with stop-the-world marking. > > > > > -> Will we use the "stop-the-world" strategy for the first release? > > > > Yes, for the first step, only the STW part is needed. The others parts > > are desirable if possible. > > > > > If not > > > (in the case of concurrent, incremental and parallel strategy), there > > are > > > some virtual memory functions that the algorithm needs: > > > 1) Map > > > 2) UnMap > > > 3) ProtN > > > 4) UnProt > > > 5) TRAP > > > 6) DoubleMap > > > So, we need to abstract that functions (to be independent of the OS in > > use), > > > and I think this abstraction should be usefull for "Mapping Collector" > > > (harmony-gc-2) . I don't know very much of the DRLVM, but I think > > > "working_vm\vm\port\src\vmem" should have those functions. > > > > Yes, to has an OS independent abstraction is good. > > > > > Cheers, > > > Humberto > > > > > > > > > > > -- > > http://xiao-feng.blogspot.com > > > -- http://xiao-feng.blogspot.com
