RE: [Gcl-devel] HEAD and GBC on Windows.

[Mike Thomas]

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.