- if (addr) {
- int flags = MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED;
- os_vm_address_t base_addr = addr;
- do {
- /* KLUDGE: It looks as though this code allocates memory
- * in chunks of size no larger than 'magic', but why? What
- * is the significance of 0x1000000 here? Also, can it be
- * right that if the first few 'do_mmap' calls succeed,
- * then one fails, we leave the memory allocated by the
- * first few in place even while we return a code for
- * complete failure? -- WHN 19991020
- *
- * Peter Van Eynde writes (20000211)
- * This was done because the kernel would only check for
- * overcommit for every allocation seperately. So if you
- * had 16MB of free mem+swap you could allocate 16M. And
- * again, and again, etc.
- * This in [Linux] 2.X could be bad as they changed the memory
- * system. A side effect was/is (I don't really know) that
- * programs with a lot of memory mappings run slower. But
- * of course for 2.2.2X we now have the NO_RESERVE flag that
- * helps...
- *
- * FIXME: The logic is also flaky w.r.t. failed
- * allocations. If we make one or more successful calls to
- * do_mmap(..) before one fails, then we've allocated
- * memory, and we should ensure that it gets deallocated
- * sometime somehow. If this function's response to any
- * failed do_mmap(..) is to give up and return NULL (as in
- * sbcl-0.6.7), then any failed do_mmap(..) after any
- * successful do_mmap(..) causes a memory leak. */
- int magic = 0x1000000;
- if (len <= magic) {
- if (do_mmap(&addr, len, flags)) {
- return NULL;
- }
- len = 0;
- } else {
- if (do_mmap(&addr, magic, flags)) {
- return NULL;
- }
- addr += magic;
- len = len - magic;
- }
- } while (len > 0);
- return base_addr;
- } else {
- int flags = MAP_PRIVATE | MAP_ANONYMOUS;
- if (do_mmap(&addr, len, flags)) {
- return NULL;
- } else {
- return addr;
- }