Address space: what's safe?

[Steve Blackburn]

 > Sorry, I don't understand why you say memalign won't cut it.  Can you
 > give an example?

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).  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.

 > Well, I would say: on x86, just mmap say 1GB or 512MB, without
 > specifying a fixed address.  This should allow plenty of room for
 > code, libraries, heap, and stack, and be as large as people would
 > probably want on that architecture.  Perhaps provide a command-line
 > parameter that sets the size so people with very large programs can be
 > bigger and take their chances.

No.  I guess we're talking at cross purposes somewhat.

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.  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.

Second, we want to provide users with as much memory as possible, and
user requests for Java heaps > 1GB are not exceptional.  We want to
squeeze as much life as possible out of the linux address space.  The
point of my email was to see if we could do better than we are
already, by tapping the brains of those who know linux better than I
do (you).

 > This is not so good because you might allocate so much VM that there
 > was no space to mmap other necessary things in the future, such as
 > dynamic libraries loaded by JNI, or data files that are mmaped.

This is part of the juggling act we're playing.  However, our
requirement is for contigious memory.  We're not about to eat all
usable virtual memory, just the biggest single contigious chunk we can
get hold of, so there should be plenty of vm for JNI, libraries, etc.

Thanks for your thoughts.

Cheers,

--Steve