gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] mac os x port questions


From: Camm Maguire
Subject: Re: [Gcl-devel] mac os x port questions
Date: 16 Feb 2004 15:47:59 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  OK I've looked over your emulation briefly, and have a few
comments.  The good news is that the issues do not appear to be major.

1) GCL has expanded its default memory allocation layout.  On the
   surface, this does not appear to pose a problem for you, as you
   allocate more than twice the heap (>1Gb) than everyone else does by
   default (512Mb).  I don't know if the start address has changed
   recently, but your first reported end range is now above the signed
   integer limit, which is likely to have caused your less than zero
   issues earlier reported, or if not, should at least prompt a review
   of your macros to make sure you use (unsigned int) where
   appropriate, e.g. page() ....

2) I really think it would be best to not hardwire the heap size, but
   rather take the value from MAXPAGE*PAGESIZE set at configure time.

3) Your strategy in my_sbrk should work, but will result in the
   maximum image size for all applications regardless of complexity.
   I don't know if your virtual memory system can realloc the heap
   without moving, but if so this would be preferable.

4) The example below, where you appear to have shrunk the heap
   substantially, is indeed too small.  At the very minimum, there has
   to be holesize+ (reloc pages) between heap_end and core_end.
   Holesize defaults to 1/10 MAXPAGE, so we see here again that we'll
   have less headaches using these macros where possible.

Will your DBEGIN vary at compile time?  If so, is it correctly
detected and propagated by configure?  Also, how does configure
autodetect your machine type?  We can modify configure.in to set the
--enable-machine variable automatically.

Take care,


Aurelien Chanudet <address@hidden> writes:

> Thanks for this clarification !
> 
> For your information, the "link edit segment" contains link edit
> information (symbol table, string table and so forth). In ELF
> parlance, this would simply be part of the data segment, so nothing
> worth your attention here. For the sake of simplification, let's not
> talk any longer of this link edit segment and do as if we simply had
> two segments (text & data) instead of three. So, let's say that my
> memory layout is the following :
> 
> - the text segment ranges from 0x00001000 to 0x0010e000
> - the data segment ranges from 0x0010e000 to 0x0077e000
> 
> What you have to know is that I'm emulating sbrk, because sbrk simply
> does not work for Mac OS X. What I'm calling a hand crafted heap is
> simply a huge block of memory that gets allocated the first time
> sbrk() is called. All memory allocation in the form of calls to sbrk()
> takes place from this huge block of memory I allocated. I'm relatively
> free as to the size of this block. However, I'm not so free as to its
> start address. More particularly, I cannot make this block contiguous
> to the end of the data segment above (0x0077e000). This is because the
> OS allocates blocks on its own before I'm given a chance to allocate
> my very first one which serves as a heap. For this reason, the lowest
> memory address I can start playing with is 0x209f6000, which I
> reported yesterday as being the start of my hand crafted heap. The
> room between 0x0077e000 and 0x209f6000 is managed by the OS.
> 
>  > Your heap should range from DBEGIN to DBEGIN + MAXPAGE*PAGESIZE.
>  > Usually the first sbrk returns an address somewhat above DBEGIN,
>  > wasting the first few pages of this range, but this is not critical.
>  > But the 'hand crafted heap' of your report begins beyond the end of
>  > this range (!)  --- 0x2010e000 should be the end.
> 
> Ok, I've adjusted the value of DBEGIN to be the start of my heap and
> set its size to be MAXPAGE*PAGESIZE. The first sbrk(0) will return
> DBEGIN, without wasting the first few pages. See gdb session
> below. Any suggestion ? Given that I have some freedom as to how my
> heap can be organized, what's the best layout ?
> 
> I don't know what a propolice gcc is.
> 
> Thanks,
> Aurelien
> 
> --
> 
> Starting program: /src/src/gcl-2.7.0/unixport/raw_pre_gcl
> /src/src/gcl-2.7.0/unixport/ -libdir /src/src/gcl-2.7.0/ < foo
> 
> Breakpoint 1, gcl_init_alloc () at alloc.c:739
> 739       if (initialized) return;
> (gdb) n
> 740       initialized=1;
> (gdb) n
> 747         malloc_list = Cnil;
> (gdb) n
> 748         enter_mark_origin(&malloc_list);
> (gdb) n
> 752       holepage = INIT_HOLEPAGE;
> (gdb) n
> 758       new_holepage = HOLEPAGE;
> (gdb) p holepage
> $1 = 15728
> (gdb) n
> 759       nrbpage = INIT_NRBPAGE;
> (gdb) p new_holepage
> $2 = 13107
> (gdb) n
> 761       set_maxpage();
> (gdb) p tm_table[t_relocatable].tm_npage
> $3 = 5242
> (gdb) s
> set_maxpage () at alloc.c:707
> 707       page_multiple=getpagesize()/PAGESIZE;
> (gdb) n
> 708       if (page_multiple==0) error("PAGESIZE must be factor of
> getpagesize()");
> (gdb) n
> 709       if (sgc_enabled)
> (gdb) n
> 712       int c = (int) MAXPAGE; /* I added this to ease debugging */
> (gdb) n
> 713       int d = (int) page(core_end); /* ditto */
> (gdb) p c
> $4 = 131072
> (gdb) p d
> $5 = 0
> (gdb) n
> 718       if (core_end)
> (gdb) n
> 724       SET_REAL_MAXPAGE;
> (gdb) n
> 726     }
> (gdb) call my_sbrk(0) ( my_sbrk is my emulation routine for sbrk )
> $6 = 0x1405000 ""
> (gdb) p mach_mapstart ( this denotes the start of my heap, yesterday's
> value was 0x209f6000 )
> $7 = 0x1405000 ""
> (gdb) p mach_maplimit ( this denotes the end of my heap, yesterday's
> value was 0x409f6000 )
> $8 = 0x1705000 <Address 0x1705000 out of bounds>
> (gdb) p real_maxpage
> $9 = 5893
> (gdb) n
> gcl_init_alloc () at alloc.c:780
> 780       INIT_ALLOC;
> (gdb) n
> 783       alloc_page(-(holepage + nrbpage));
> (gdb) p heap_end
> $10 = 0x1405000 ""
> (gdb) p core_end
> $11 = 0x1405000 ""
> (gdb) p holepage
> $12 = 15728
> (gdb) s
> alloc_page (n=-20970) at alloc.c:100
> 100             e = heap_end;
> (gdb) n
> 101             if (n >= 0) {
> (gdb) n
> 144             n = -n;
> (gdb) n
> 145             m = (core_end - heap_end)/PAGESIZE;
> (gdb) n
> 146             if (n <= m)
> (gdb) p m
> $13 = 0
> (gdb) n
> 149             IF_ALLOCATE_ERR error("Can't allocate.  Good-bye!");
> (gdb) n
> my_sbrk(): no more memory
> MAXPAGE = 131072
> page(core_end) = 0
> 
> Unrecoverable error: Can't allocate.  Good-bye!.
> 
> Program received signal SIGABRT, Aborted.
> 0x90042aac in kill ()
> (gdb) p n
> No symbol "n" in current context.
> (gdb) p core_end
> $14 = 0x1405000 ""
> (gdb) p mach_maplimit-mach_mapstart
> $15 = 3145728
> (gdb) p (mach_maplimit-mach_mapstart)/0x1000
> $16 = 768
> (gdb) quit
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
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]