site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. This email sent to site_archiver@lists.apple.com