Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com
 designates 74.125.46.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=IwOA5xeGzqwhuSno077leD5PkudBLpV36RiipPWyhn+SGagTzs8jwEkX93vKvbxNM83/wbZJ16wjVfSQtaKPe4y4hk9ljdK+Z1x951O3p9kKb9++iDMiFkkw25b5oqpHJPN1cHU0DaFEXngsY15zoU7n/3ANs79ftNVLGJx3O1k=
Message-ID: <9623c9a50804111741q5d32fue2c7b58fed58c7f6@mail.gmail.com>
Date: Sat, 12 Apr 2008 08:41:01 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [GSoC] About harmony-gc-1 "Compressor GC"
In-Reply-To: <e04821570804110633i5398d51ds19d983ff3609843b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e04821570804091357g5cd4d38drc96ef2cc5bcf3502@mail.gmail.com>
	 <9623c9a50804091851p7ee20444ka64b9e8b0f5aec60@mail.gmail.com>
	 <e04821570804110633i5398d51ds19d983ff3609843b@mail.gmail.com>

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 <hsnaves@gmail.com> 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 <xiaofeng.li@gmail.com> wrote:
>
>  > On Thu, Apr 10, 2008 at 4:57 AM, Humberto Naves <hsnaves@gmail.com> 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