[Top][All Lists]
[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
- Re: [Gcl-devel] mac os x port questions, (continued)
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/13
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/14
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/14
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/14
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/15
- Re: [Gcl-devel] mac os x port questions,
Camm Maguire <=
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/15
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/15
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/16
- Re: [Gcl-devel] mac os x port questions, Aurelien Chanudet, 2004/02/18