[Gc] question about mmap code

Boehm, Hans hans.boehm at hp.com
Wed Mar 10 17:44:25 PST 2004

Tom -

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 
> 		    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
> reason?
> 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.
> Tom
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list