code review 40610044: runtime: be explicit about whether all the memory behin...

runtime: be explicit about the reservation of all the memory behind the heap

Various parts of the runtime use "sizeof(void*) == 8 && (uintptr)v >= 0xffffffffU" to try to determine if we are in "64-bit" or "32-bit" mode for allocation, the main difference between the modes being whether the heap has all its address space allocated to it by the kernel or not yet.

As well as being mighty obscure, this can be _wrong_: if the attempt to map the heap around 0xc000000000 fails on a 64-bit system, we switch to the "32-bit" mode for allocating the heap, and it's perfectly possible for this heap to still end up way beyond 0xffffffffU.

I found this on aarch64, where only 512Gb of address space is available to a process and so clearly we should try to put the heap somewhere else; this is still a bug though.

The bug is present in the go distribution too.

This code is not really a serious attempt at a fix, I'm only just compiling it now.  Thoughts welcome though!

Fixes issue 6926

[mwhudson, 2013-12-11 02:45:40]

Hello gofrontend-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/gofrontend/

[dave_cheney.net, 2013-12-11 02:49:08]

On 2013/12/11 02:45:40, mwhudson wrote:
> Hello mailto:gofrontend-dev@googlegroups.com,
> 
> I'd like you to review this change to
> https://code.google.com/p/gofrontend/

Thanks Michael, 

iant/michael: I'm wonding if this should land in Go first, then be backported to
gccgo

[mwhudson, 2013-12-11 08:56:17]

On 2013/12/11 02:49:08, dfc wrote:
> On 2013/12/11 02:45:40, mwhudson wrote:
> > Hello mailto:gofrontend-dev@googlegroups.com,
> > 
> > I'd like you to review this change to
> > https://code.google.com/p/gofrontend/
> 
> Thanks Michael, 
> 
> iant/michael: I'm wonding if this should land in Go first, then be backported
to
> gccgo

Yes, probably.  I'll send something to golang-dev tomorrow.