Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of mike.fursov@gmail.com
 designates 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=gL2QJkuz4cUggtRFw4IS78PhaCiNhTolgaXRRUxoy1//w4I6aiQYhUjikJx0jDfwD/L9RKf3ZUSiynEXVKr5N6Kbga7nP0MhdlTpZT9qPJguog/SW3An4on2fkVrNeRsdifHgzw6IhQn7sPp2JYkbzx9Xz29y7Wr7oOlxsUcVtA=
Message-ID: <bc79dd600610300803j1a15244m8e58defabf84c584@mail.gmail.com>
Date: Mon, 30 Oct 2006 22:03:11 +0600
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][GC] parallel compaction and wasted virtual space
In-Reply-To: <51d555c70610300753n4fd400cvaccbf789c29b664d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_68415_21887261.1162224191194"
References: <9623c9a50610271902x4fdbe815m246b1739d499a756@mail.gmail.com>
	 <51d555c70610300753n4fd400cvaccbf789c29b664d@mail.gmail.com>

------=_Part_68415_21887261.1162224191194
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Is it the same?
http://citeseer.ist.psu.edu/630853.html
or
http://www.cs.technion.ac.il/~erez/Papers/parallel-compaction.ps

On 10/30/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Hi,
>   Does anyone have an accessible reference to the OOPSLA paper "An
> efficient
> parallel heap compaction algorithm" by Abuaiadh, Ossia, Petrank,
> Silbershtein ....that is cited as a reference in the paper Xiao Feng
> points
> to below? All my google searches lead to the ACM Portal :-)
>
> Thanks,
> Rana
>
>
> On 10/27/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > Hi, all, the plan for GCv5 parallel compaction is to apply the idea of
> > Compressor [1]. But it has an issue I want to discuss with you.
> > Compressor needs to reserve an unmapped virtual space for compaction.
> > The size of the reserved part is the same as that of copy reserve
> > space in a semi-space collector. This means about that part of the
> > virtual space is unusable for the JVM. In a typical setting, the
> > wasted part is half size of the total compaction space. If we have 1GB
> > physical memory, the JVM is ok for Compressor because the virtual
> > space is large enough to wast half; but if the phsical memory is >2GB,
> > Compressor may have a problem in 32bit machine: some of phsical mapped
> > space might be wasted.
> >
> > Any opinion on this?
> >
> > Thanks,
> > xiaofeng
> >
> > [1] http://www.cs.technion.ac.il/~erez/Papers/compressor-pldi.pdf
> >
>
>


-- 
Mikhail Fursov

------=_Part_68415_21887261.1162224191194--