runtime: prepare for 8K pages

runtime: prepare for 8K pages
Ensure than heap is PageSize aligned.

[dvyukov, 2014-01-24 15:44:32]

Hello iant@golang.org (cc: golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://dvyukov%40google.com@code.google.com/p/go/

[dvyukov, 2014-01-27 11:27:52]

On 2014/01/24 15:44:32, dvyukov wrote:
> Hello mailto:iant@golang.org (cc: mailto:golang-codereviews@googlegroups.com),
> 
> I'd like you to review this change to
> https://dvyukov%2540google.com%40code.google.com/p/go/

+Dave as owner of darwin builders

[dave_cheney.net, 2014-01-29 00:46:54]

This passes on darwin-amd64, over to ian and minux for review

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc
File src/pkg/runtime/malloc.goc (right):

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc...
src/pkg/runtime/malloc.goc:440: // To overcome this we ask for PageSize more and
round up the pointer.
for /a/ PageSize more

[gobot, 2014-01-29 00:47:27]

R=iant@golang.org (assigned by dave@cheney.net)

[iant, 2014-01-29 01:09:53]

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc
File src/pkg/runtime/malloc.goc (right):

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc...
src/pkg/runtime/malloc.goc:438: // PageSize can be larger than OS definition of
page size,
Why aren't we doing this for the 64-bit case above?  Doesn't the same issue
potentially arise?  That is, why not also add PageSize above, and move this
ROUND call out of this conditional?

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc...
src/pkg/runtime/malloc.goc:443: if((uintptr)p & (PageSize-1)) {
If we do the above--if we always use ROUND--then there is no need for this test.

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/mem_darwin.c
File src/pkg/runtime/mem_darwin.c (right):

https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/mem_darwin...
src/pkg/runtime/mem_darwin.c:80: p = runtime·mmap(v, n, PROT_READ|PROT_WRITE,
MAP_ANON|MAP_PRIVATE|MAP_FIXED, -1, 0);
On some systems an mmap call with MAP_FIXED will overwrite any existing
mappings, which is why mem_linux.c has the addrspace_free code.  Can you confirm
that this does not happen on Darwin--that the MAP_FIXED call will fail if there
are existing mappings in that portion of the address space?

[dvyukov, 2014-01-29 10:36:36]

On 2014/01/29 01:09:53, iant wrote:
> https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc
> File src/pkg/runtime/malloc.goc (right):
> 
>
https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc...
> src/pkg/runtime/malloc.goc:438: // PageSize can be larger than OS definition
of
> page size,
> Why aren't we doing this for the 64-bit case above?  Doesn't the same issue
> potentially arise?  That is, why not also add PageSize above, and move this
> ROUND call out of this conditional?
> 
>
https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/malloc.goc...
> src/pkg/runtime/malloc.goc:443: if((uintptr)p & (PageSize-1)) {
> If we do the above--if we always use ROUND--then there is no need for this
test.
> 
>
https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/mem_darwin.c
> File src/pkg/runtime/mem_darwin.c (right):
> 
>
https://codereview.appspot.com/56630043/diff/40001/src/pkg/runtime/mem_darwin...
> src/pkg/runtime/mem_darwin.c:80: p = runtime·mmap(v, n, PROT_READ|PROT_WRITE,
> MAP_ANON|MAP_PRIVATE|MAP_FIXED, -1, 0);
> On some systems an mmap call with MAP_FIXED will overwrite any existing
> mappings, which is why mem_linux.c has the addrspace_free code.  Can you
confirm
> that this does not happen on Darwin--that the MAP_FIXED call will fail if
there
> are existing mappings in that portion of the address space?




Local darwin expert here says that MAP_FIXED can overwrite existing mappings on
darwin as well.
There seem to be mach syscall that does what we want -- fixed alloc w/o
overwriting.
But instead I've done what you proposed -- align heap on page size always. Now
the CL does not touch OS-specific code at all and become simpler.

PTAL

[iant, 2014-01-29 14:07:11]

LGTM

[dvyukov, 2014-01-29 14:18:54]

*** Submitted as https://code.google.com/p/go/source/detail?r=2ca683523bf0 ***

runtime: prepare for 8K pages
Ensure than heap is PageSize aligned.

LGTM=iant
R=iant, dave, gobot
CC=golang-codereviews
https://codereview.appspot.com/56630043

[gobot, 2014-01-29 14:24:29]

This CL appears to have broken the dragonfly-amd64 builder.