Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=g2jkFRN542zEMMcdghiXy8kNmUh8gOWb71ZU5OeJ5IWbgfiIm314A5eifnFCA9ASerlQ33qpHyOtyupuNkddYFrc/YQbDn2KoosLZdAvSXWGP1KhHJrqGF9ZCgz88HM2YIsSmg2sOZZwtOiLo8WTk+is9Lg5fX/fLfSQLXWiWz4=
Message-ID: <9623c9a50702151824k11a09dfbu5a484b569c8a02be@mail.gmail.com>
Date: Fri, 16 Feb 2007 10:24:59 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM][GC] low pause garbage collection for Harmony
In-Reply-To: <12385bbd0702150322i20d5c7a8pf32cf38696c2ed07@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50702131847p52f47a7n589d84d193ab56d9@mail.gmail.com>
	 <12385bbd0702150322i20d5c7a8pf32cf38696c2ed07@mail.gmail.com>

On 2/15/07, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> On 2/14/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > Some researchers seperate "on-the-fly" GC from concurrent GC as a
> > special case [3]. The difference as stated is "on-the-fly" GC doesn't
> > require any synchronization point where all mutators are suspended,
> > i.e., it suspends and resumes mutators one after another, not at the
> > same time. There is also "real-time" GC proposed that can satisfy
> > required real-time bounds. Metronome is one example [4].
>
> > [3] http://www.cs.technion.ac.il/~erez/Papers/ms-sliding-views.ps
>
> I have taken a look at the ms-sliding-views.ps paper. The on-the-fly
> GC looks quite promising. One thing that bothers me is it is of 'mark
> and sweep' type. It require different allocator algorithm to keep
> fragmentation low, it means for me (correct me) that the allocation
> rate would be rather slow and it will have suboptimal data locality. I
> understand that we won't have such low pauses if we would like to move
> data on a GC without read barriers. One thing which really excite me
> that it doesn't require stop-the-world at all, each thread is stopped
> independently, that means that it's really scalable by the number of
> running threads.

Ivan, thanks. I have basically the same understanding of the
on-the-fly mark-sweep algortihm as you. It may need compaction
algorithm to reduce the accumulated fragmentation effect. Compressor
can compact the heap with rather low pause-time by leveraging the OS
mem-protect mechanism and tripple-mapping the virtual space.

Thanks,
xiaofeng

> --
> Ivan
> Intel Enterprise Solutions Software Division
>