[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Camm Maguire
Subject: Re: [Gcl-devel] HEAD and GBC on Windows.
Date: 14 Dec 2005 09:24:41 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Argh -- this is that old issue that's been in GCL forever -- as
ambiguously denoted in my diagram, DBEGIN has always traditionally
been below the first sbrk, usually enforced by the malloc address
truncation in configure, and causing a certain amount of wastage at
the beginning of the type_map and sgc_type_map arrays.  On unix with a
working sbrk, one never has the luxury of specifying the first sbrk(0)
with any but the crudest degree of precision, as it depends on the
program header, text code size, linker version, etc.  So DBEGIN is
conceptually a configure-time determined known anchor guraranteed not
to exceed the first sbrk(0), and to be reasonably close thereto.

In CVS head, we're scaling the holesize with the size of core, which
seems reasonable.  This means, however, that after INIT_ALLOC, one
needs a non-zero core unless one wants an exception at this point.
One idea is to put a floor on holepage et.al. throughout and let the
first alloc_page generate a non-zero core.

At this burning moment, the easiest thing to get going is to define
DBEGIN somewhat below where your first sbrk(0) will start.  Then maybe
we can discuss and figure out what we want to do.

Please keep me posted.

Take care,

"Mike Thomas" <address@hidden> writes:

> 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,
> 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.

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]