| > It is necessary to fix the way limits are handled for the data segment
| > before you can even consider making this change.
| > 
| If nothing is done to the way limits are handled it will be (almost)
| no difference compared to now.

No, you are changing the way that process address spaces are laid out.
There is quite a bit of handwaving about the in-kernel aspects of this
change, but the code snippet you have provided uses mmap(NULL, ...)
which will allocate space out of the mmap() part of the address space
rather than the sbrk() part of the address space.  This means that 
the space that would originally have been allocated at the end of the
data segment will now be allocated below the stack.  Since the current
address space layouts for different machines were not designed with this
in mind it could cause processes to run out of address space if the 
MMU has an inconveniently located VM hole.

If you change mmap() to allocate at the end of the data segment you
potentially break any application that interleaves mmap() and sbrk().

Changing mmap() behavior after a call to sys__sbrk15() can also lose
if the dynamic linker or one of the libraries it loads calls mmap()
before the legacy application calls sys__sbrk15().

Quite some thought has gone in to trying to squeeze the maximum
useable address space out of some machines.  You need to address 
these issues and make sure they don't break on any architecture 
before deprecating sbrk().

Eduardo