Hi Camm. | > (gdb) n | > 985 INIT_ALLOC; | > | | Here is the origin of the problem it seems. From what I can | see, mingw is using the def from att.h, which calls sbrk(0) | with some page rounding. Either this is not setting core_end | above DBEGIN, or (more | likely) something is wrong with the arithmetic in | | #define CORE_PAGES (((ufixnum)core_end-DBEGIN)>>PAGEWIDTH) | | BTW, PAGESIZE is always a power of 2 on the machines I work | on, and indeed is defined (if memory serves) as (1<<PAGEWIDTH).
See below. | | I'm not sure if I follow the meaning of reserve vs. commit below. See stuff at bottom from MSDN. | | What is PAGEWIDTH? Is DBEGIN an unsigned fixnum? What is | core_end here? >From gclincl.h: #define DBEGIN 0x3000000 #define MAXPAGE 262144 #define VSSIZE 131072 #define BDSSIZE 2048 #define IHSSIZE 4096 #define FRSSIZE 4096 #define CSSIZE 2293759 #define HOLEDIV 4 #define PAGEWIDTH 12 Extended debugging output: allocate_heap: base 3000000, end 3d000000, reserved_heap_size 3a000000, PAGESIZE 1000, MAXPAGE 40000, MAXCORE 42fff000, INIT_NRBDIV 9, INIT_HOLEDIV 3, HOLEDIV 4, DBEGIN 3000000, PAGEWIDTH c gcl_init_alloc: PAGESIZE 1000, MAXPAGE 40000, MAXCORE 42fff000, CORE_PAGES 0, core_end 3000000, INIT_NRBDIV 9, INIT_HOLEDIV 3, HOLEDIV 4 It looks like CORE_PAGES is working as required: (0x3000000 - 0x3000000) = 0 >> 12 = 0 >From what you are saying, INIT_ALLOC should actually be allocating a non-zero quantity of pages ie sbrk() should be called on some fixed quantity of pages to set (core_end > heap_end). What should that quantity be in your opinion? Does Linux use the same mechanism? | | Take care, and thank you as always!!!!! | Cheers Mike Thomas MSDN reserved and committed information When reserving addresses in a process, no pages of physical memory are committed, and perhaps more importantly, no space is reserved in the pagefile for backing the memory. Also, reserving a range of addresses is no guarantee that at a later time there will be physical memory available to commit to those addresses. Rather, it is simply saving a specific free address range until needed, protecting the addresses from other allocation requests. Without this type of protection, routine operations such as loading a DLL or resource could occupy specific addresses and jeopardize their availability for later use. Reserving addresses is a quick operation, completely independent of the size of the address range being reserved. Whether reserving a 1 GB or a 4K range of addresses, the function is relatively speedy. This is not surprising considering that no resources are allocated during the operation. The function merely makes an entry into the process's virtual address descriptor (VAD) tree. For information about VADs, see "The Virtual-Memory Manager in Windows NT" on the Developer Network CD (Technical Articles, Win32 and Windows NT Articles). To use reserved addresses, memory must first be committed to the addresses. Committing memory to addresses is similar to reserving it-call VirtualAlloc with the dwAllocation parameter equal to MEM_COMMIT. At this point, resources become committed to addresses. Memory can be committed as little as one page at a time. The maximum amount of memory that can be committed is based solely on the maximum range of contiguous free or reserved addresses (but not a combination of both), regardless of the amount of physical memory available to the system. When memory is committed, physical pages of memory are allocated and space is reserved in a pagefile. That is, pages of committed memory always exist as either physical pages of memory or as pages that have been paged to the pagefile on disk. It is also possible that, while committing a chunk of memory, part or all of that memory will not reside in physical memory initially. Some pages of memory reside initially in the pagefile until accessed. Once pages of memory are committed, the virtual memory manager treats them like all other pages of memory in the system. _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel