[Gc] question about mmap code
hans.boehm at hp.com
Wed Mar 10 17:44:25 PST 2004
That's an interesting question.
It should certainly be safe to pass NULL instead. The collector prefers
contiguous memory to avoid fragmentation issues at the boundaries between allocated
Based on a quick conversation with David Mosberger and a look on the web,
the glibc spec possibly agrees with SUSV3 (there is some ambiguity), but Linux
does not replace mappings unless MAP_FIXED is specified.
Furthermore this interpretation of SUSV3 or the glibc spec
makes no sense to either of us; I can think of no case in which you want the system
to replace an existing mapping based on "a suggestion" of an address. This is
reasonable behavior only if MAP_FIXED is specified. And it may be that that's
what the spec is trying to say.
Unless we know that some system really replaces mappings without MAP_FIXED, I would
view this as a defect in the spec, not a bug in the GC.
There were real problems along these lines with -DUSE_MUNMAP, since the unmapped
region could be used by something else in the interim. Very recent versions of
the GC avoid this by replacing the old mapping with a new inaccessible one,
instead of unmapping.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Tom Tromey
> Sent: Wednesday, March 10, 2004 3:54 PM
> To: GC List
> Subject: [Gc] question about mmap code
> Recently I ran into a problem on a PPC Linux machine, where a certain
> invocation of gij (the java bytecode interpreter that comes with gcj)
> will give:
> Out of Memory! Returning NIL!
> This occurs on a development OS and in a hard-to-set-up environment.
> We've also got a patch in the GC to always enable USE_MMAP on Linux.
> Anyway, I took a look at the mmap code:
> static ptr_t last_addr = HEAP_START;
> result = mmap(last_addr, bytes, PROT_READ | PROT_WRITE
> | OPT_PROT_EXEC,
> GC_MMAP_FLAGS | MAP_ANON, -1, 0/* offset */);
> if (result == MAP_FAILED) return(0);
> last_addr = (ptr_t)result + bytes + GC_page_size - 1;
> This seems a bit odd to me. Won't this cause problems if the process
> is calling mmap elsewhere? According to the glibc manual:
> ADDRESS gives a preferred starting address for the mapping.
> `NULL' expresses no preference. Any previous mapping at that
> address is automatically removed.
> So couldn't we end up unmapping memory already mapped for some other
> I'm not certain that this is what is happening in my situation
> (unfortunately debugging on this machine is also problematic...). It
> is just one theory I had.
> Does the GC need memory to be mapped in contiguous regions like this?
> Could we instead just `mmap(NULL, ...)'? I haven't found the time to
> try this yet, but I probably will sooner or later.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc