X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=sucAvSWI+Ow+X0Fydne1cwFILKaqeWbJcleGx+EIAKMFMnV6o8qUZ
	8rVpMKaFJdbvd4NTlBBRc6TSYfGnDBy2IlaNZBMxYDoQKnOZjPgA/eQHrcWGPe6C
	R1xGuWCDO0RjLGKy8+I430yDxK8TGhTE5Xou0BkPqeZF+4N5cELfQg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=IWFC5RwCtcW5ugqxT+36lycXOYI=; b=fZ0dewN85EkOy7+9AyPNYKVUiT6j
	sFlxHLQULZBidyCIhL2wojcGxs+um3+UI+bwgB70Uy2/k+0GVUvyhbR0jr5Zjtm4
	sfpbluCWO8YfkQPQgcmrNgBnu+qj2/n+RoGwulDtdwxSpsR07nBONISuAUd0KYO6
	eaQI6OuXuO7TKz8=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-93.9 required=5.0 tests=BAYES_50,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=4GB, 4gb, increaseuserva, bcdedit
X-HELO:	calimero.vinschen.de
Date:	Wed, 20 Apr 2016 13:14:31 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Process map and fork problems
Message-ID:	<20160420111431.GB13570@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<loom DOT 20160420T121651-786 AT post DOT gmane DOT org> <20160420104633 DOT GA26118 AT calimero DOT vinschen DOT de> <loom DOT 20160420T124825-644 AT post DOT gmane DOT org>
MIME-Version:	1.0
In-Reply-To:	<loom.20160420T124825-644@post.gmane.org>
User-Agent:	Mutt/1.5.24 (2015-08-30)

--yEPQxsgoJgBvi8ip
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 20 11:01, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > This is one heap.  The first region is just the already committed
> > part, the remainder is the reserved part.
> >=20
> > THis is the standard Cygwin heap area on 32 bit machines, which always
> > starts at 0x20000000.
>=20
> So, shouldn't rebase keep this area clear on these machines?
>=20
> > On 64 bit systems, 32 bit applications have a 4 Gig virtual address
> > space.  On 32 bit systems, procecces only have a 2 Gig virtual address
> > space, unless the /3gb kernel option is given.
>=20
> OK.  On Windows7 that means 'BCDedit /set increaseuserva=3D3072', right?

Yeah, I think so.  /3gb is the old XP way to define it.

> I think all the affected machines have 4GB memory installed, but the
> option may not have been default when they were installed.

They never are default.  Default is 2 Gigs application VM, 2 Gigs
kernel=CC=87 memory space.  Specifying /3Gb means 3 Gigs application VM
vs. 1 Gig kernel=CC=87 memory space.  That's not always a good thing
since it could lead to kernel memory pool exhaustion.

> > On 64 bit systems and on /3gb enabled 32 bit systems, the heap of 32 bit
> > Cygwin processes always starts at 0x80000000L.
> >
> > Since that isn't available on 32 bit systems by default, the heap has
> > to start within the lower 2 Gigs.  That's where the 0x2000000 address
> > comes from.
>=20
> With /3GB you mean 4GT (aka PAE), right?  And 32bit is without PAE?

No, PAE works differently, using different calls.  I'm talking abut
the normal 32 bit address space of a 32 bit CPU.

> > If you have collisions because you're providing too many Cygwin DLLs,
> > you have to tweak these installations manually.
>=20
> As long as Cygwin determines automatically where the heap is located, then
> rebase should take care of that.  It already knows to skip the cygwin1.dll
> address range, how would it ask for the heap location?

It can only know its own heap.  But keep in mind that the heap can
be differently sized in different applications.  The heap only *starts*
as a 384Meg heap, it could easly grow in big apps (gcc, emacs, ...)
when calling sbrk.

Patches welcome, of course.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--yEPQxsgoJgBvi8ip
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXF2SXAAoJEPU2Bp2uRE+g/2UP+wTWnxoKy29lB7yqvyUo1gZl
RaazKmenR71OGynqZ3P8+LWjERm6DSDQwU+TtqsXh5XcA223k1QSSID3QQWEpBki
VVbiqs/odR8Fxs8/DVxSjVlefuF0lINtj1qBUfxJEb/BMwM3fEvV5/rJqovkRzMV
iGAU8eCNEcdSK/XMcw6UvmLhg76IdcJV8q1CH0zFhFU9uHPbaAUVIauAKbBf/ifd
Tm++vRE9+dNwJhM27+e1cg//r+Pgzz+YFrwfAyF6nQTbGmVAuMqGQigV88xSsljJ
Qt+tf4jKeDNde1zxTYfs3ieB7si9mIIDG3/Juzgih8h+1yuHt2OkX54RTzul8c+C
JBt+TaMcsHYyLCNgx3MqrU2o0bpsQ88ZxmUoI04HSxhouHugZotuziAwXBZDtj1S
RDw5rr10esCYWnli+GxByt9fuUcJaaQH6oSLA9oORHnskC1U6XuJCfePriJvtL3H
tVLDZ3DjSEFOqHjRPsAgxV7nktGQijBctxe2DFRWH5b/0ceNkycs34D+A7HTAwo5
ijRk+HqkbUO7xTk87oAcdwK6wRV5IDrjVi9mcFdQ21+N8mREXr9A35uGLbJ3uclR
fe3A1/j8klHl0RpRmX2uwsa2n84KSms+u9wAbQyznXmrO69nWyz9r6LFmdw7wsHv
+HuMM17km0gGjmvilx3A
=5di/
-----END PGP SIGNATURE-----

--yEPQxsgoJgBvi8ip--

- Raw text -