From:	cgf AT cygnus DOT com
Subject:	(none)
8 Apr 1998 06:46:01 -0700 :
Message-ID:	<199804081301.JAA24373.cygnus.cygwin32.developers@tweedledumb.cygnus.com>
To:	cygwin32-developers AT cygnus DOT com

>From: ian AT cygnus DOT com (Ian Lance Taylor)
>Date: 7 Apr 1998 21:03:43 -0700
>
>>From: Geoffrey Noer <noer AT cygnus DOT com>
>>Date: Tue, 7 Apr 1998 18:41:15 -0700 (PDT)
>
>>Sergey Okhapkin wrote:
>>> 
>>> Now I know why _every_ cygwin process have a splitted heap if it allocates 
>>> more than heap_chunk_size bytes of memory (but I will not tell you why this 
>>> happens - think yourself!-) Here is the temporary fix - reserve a large 
>>> amount of memory for heap to avoid fork problem. The fix doesn't affect 
>>> performance.
>>> 
>>> H:\usr\src\cygnus\cdk\winsup>diff -u shared.cc.orig shared.cc
>>> --- shared.cc.orig      Wed Feb 11 06:15:08 1998
>>> +++ shared.cc   Tue Mar 24 10:44:55 1998
>>> @@ -96,7 +96,7 @@
>>> 
>>>    reg_session reg;
>>> 
>>> -  heap_chunk_in_mb = reg.get_key ().get_int ("heap_chunk_in_mb", 8);
>>> +  heap_chunk_in_mb = reg.get_key ().get_int ("heap_chunk_in_mb", 128);
>>>    if (heap_chunk_in_mb < 4)
>>>      {
>>>        heap_chunk_in_mb = 4;
>>
>>Are there reasons why I shouldn't make this change?
>
>On a traditional Unix system, making this change would mean that every
>process would require 128 MB in the swap file, and your system would
>rapidly run out of swap space.  I don't know how the Windows
>equivalent of a swap file works, so I don't know whether there would
>be any equivalent problem.

Since the this just essentially sets aside a contiguous address range I
could envision an OS which would be intelligent enough to avoid allocating
swap space until parts of the memory region were committed.  I'm having
a difficult time, however, imagining a *Windows* operating system that
would be this intelligent.

Hmm.  I wonder if this is discussed in DejaNews or in Microsoft Knowledge
Base?

There are two other ways to "solve" this problem.

1) Teach fork to copy a noncontiguous heap.

   I'd be happy to tackle that one.  I don't think it would be *that*
   hard.

2) (band-aid) Delay heap allocation until all of the standard threads
   have been started up.  It is apparently the stacks that are allocated
   for the thread that are getting in the way of the heap.

3) Another thing just occurred to me.  We could have a wrapper around
   CreateThread which would:

	VirtualAlloc(u->base, ridiculously_large_value,
		     MEM_RESERVE, PAGE_READWRITE)
        ReallyCreateThread(..)
	VirtualAlloc(u->base, u->size, MEM_RESERVE, PAGE_READWRITE);

    I don't know if we can count on stack creation in the thread to be
    handled before CreateThread returns, though.

cgf

- Raw text -