Address space: what's safe?

[Martin Pool]

On  7 Mar 2003, Steve Blackburn <Steve.Blackburn at anu.edu.au> wrote:

> I think at this point you should just take my word for it that I care
> not only about the size and alignment of my request, but its location
> (with respect to other requests).

OK.

> Also (and possibly unrelated), with my large reserved space, I only
> want to pay for swap as I need it, so I would want to reserve the
> large space initially and then re-mmap with backing swap as
> required.

I think by default no swap will be committed until you write to the
pages or request that it be so.  Or at least you can request this
MAP_NORESERVE on kernels that do precommit.  I don't think this is a
reason not to map a maximally-sized region up front.

> First, the question is where, and as I have already said, the exact
> alighment and relative location is an issue: some GC algorithms
> require, for example, that half the heap be on one side of an
> alighment boundary and half on another.

OK, that makes it clearer.

> To the extent that I depend on such boundaries, I really want to
> compile those constants into the VM at build time, for obvious
> performance reasons.  Please just take my word for it, or if not,
> have a look at the JMTk code or a GC text.

I think you cannot reliably compile it in.  The kernel and libc don't
make any promises about whether things will be, although there are
patterns.  It might well vary with e.g. highmem or PAE kernels (I
haven't checked), or with future libcs.

So, given all this, I think your best bet might in fact be to read
/proc/self/maps.  You're now allowed to do it :-) and it's more
hygenic than making assumptions about where things will be.

As you can see by looking at this for typical programs, libraries are
normally loaded from 0x40000000 up and the stack starts at
0xbfff7000.  So somewhere around 0x50000000 ought to be safe.

Another option might be to statically link your program.

It's easy to read, and that will tell you which parts of the space are
currently used and you can then find some suitable range that won't
clash.  ld.so seems to map new libraries without a fixed address, so
they should fit in around it.

I suppose you already thought of this?

-- 
Martin