Re: Problem using .zerofill / -segaddr to create very large segments
Re: Problem using .zerofill / -segaddr to create very large segments
- Subject: Re: Problem using .zerofill / -segaddr to create very large segments
- From: Terry Lambert <email@hidden>
- Date: Tue, 22 Sep 2009 15:22:09 -0700
On Sep 22, 2009, at 1:50 PM, Jay Reynolds Freeman wrote:
Terry, I think you came in late on this: The problem is, I am doing
mmapping, and I need a big block of memory at the *same* virtual
address
in each of several processes (because that block contains pointers
to locations within itself).
You have a LISP runtime which you are using internal compilation to
generate code for language extensions and stuffing them into your heap
area, and then l;ater reloading them as precompiled language
extensions. The code is not PIC, so you want the code loaded at the
same location so that the data structures and code can be found by the
runtime. Right so far?
You need to grab a big chunk in the middle of your address space, and
not in your heap. If at all possible, you also need to arrange your
code generation such that your normal access pattern isn't sparse in
the memory region you allocate. Ideally, you'd fix the runtime to
support PIC code generation so you can relocate segments for locality
of reference to keep the address space access patterns non-fragmented
over time (via feedback).
The processes are 64-bit applications that run in Snow Leopard. They
can use of all the memory you can put in a Mac Pro, and then some.
I have
a parallel lisp system with a dual-memory scheme for garbage
collection --
the memories are most of what goes in the shared segment. I want
to allow each of those memories to be as large as the most RAM you
can have in a Mac, which I believe is 64 GByte today.
I am sure I can find plenty of room in any one process's address
space,
but the interprocess coordination required to make *certain* that
all of the
interested processes can find a block at the *same* address is a mess.
I feel strongly that I should seek a simpler solution.
If you perform an mmap() very early on of zero-fill pages, then you
can do it as a .constructor or as part of an early constructor, or
very early in your runtime, and that will ensure that you get the
common mapping that you want. You really do not want to use all
those .zerofill's; I haven't seen the output of your otool -l, but I
rather suspect that each one might be getting it's own LC_SEGMENT_64.
You may also be generating LC_SEGMENT's and linking them in instead
(which gets you a 32 bit limit).
The output of vmmap on the running process (without the
161st .zerofill) would probably be informative. You may also want to
look at the man pages for dyld, since there are a bunch of environment
variables you can set to get more extensive diagnostics.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden