Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of xiaofeng.li@gmail.com designates
 64.233.182.185 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:content-transfer-encoding:content-disposition:references;
        b=idYBYBwBlZ+MPGVS/ei6H6Jj282+ZdmJE03nAt09DchmRh5usKqNrlP3xv1F0lIwRHAB0O/tzBoOzkqKZAwotXOnrqytyg+H/ifMML4xiYfIY1l24LxtdnglCGzHJRHFU318yJPOr05292U1x8kcEPeNXN8lL0KkpJT9rKLDfOM=
Message-ID: <9623c9a50607300336q7efeed54v6b54456c70a4feb8@mail.gmail.com>
Date: Sun, 30 Jul 2006 18:36:52 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
In-Reply-To: <87d5bnv2vy.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <636fd28e0607290058q21566ec0uad96426092ad891a@mail.gmail.com>
	 <9623c9a50607290535p19d6a6eesc43769f52d5381fa@mail.gmail.com>
	 <87d5bnv2vy.fsf@mid.deneb.enyo.de>

Agree that maximum size is still desirable for system stability
reason. :-)  ( I hope the OS MM can be more intelligent to deal with
overcommitment.)  But here in this specific discussion context, I
think the word `unlimit' or `infinite' is meaning `unlimit under
certain limit'. Whatever the limit is can be defined by the clever OS
(which returns a ENOMEM, for example) or user heuristics.

Thanks,
xiaofeng

On 7/30/06, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Xiao-Feng Li:
>
> > 1. the GC design usually hopes to have continuous memory space. The
> > dynamic heap increase and decrease may have difficulty to interact
> > with OS so as to keep the GC heap continuous.
>
> At least on Linux, you can mmap with PROT_NONE to reserve an address
> range, and later populate it with backing storage with mprotect.
> (Initially, the reserved address space does not count against the
> reserved memory counter of the process.)  Unfortunately, on 32-bit
> systems, the available address space will be somewhat fragmented, so
> you still need to support different regions.
>
> For robustness purposes, I fear you still need the maximum heap size
> on Linux, unless overcommitment is turned off (which is not the
> default).  Otherwise, some process just dies (not necessarily the VM
> that has gone awry), which can have a huge impact on system stability.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org