code review 4148045: runtime: new allocation strategy for amd64

runtime: new allocation strategy for amd64

Do not reserve virtual address space.
Instead, assume it will be there when we need it,
and crash loudly if that assumption is violated.
Reserving the address space gets charged to
ulimit -v, which exceeds commonly set limits.

http://groups.google.com/group/golang-dev/msg/7c477af5f5a8dd2c

[rsc, 2011-02-09 16:19:26]

Hello r (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg

[niemeyer, 2011-02-09 17:39:57]

One detail I wondered:

http://codereview.appspot.com/4148045/diff/7001/src/pkg/runtime/linux/mem.c
File src/pkg/runtime/linux/mem.c (right):

http://codereview.appspot.com/4148045/diff/7001/src/pkg/runtime/linux/mem.c#n...
src/pkg/runtime/linux/mem.c:60: p = runtime·mmap(v, n,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANON|MAP_PRIVATE, -1, 0);
Isn't it Missing MAP_FIXED here, since it's still not
just a hint?  It looks like the mmap should be the same
as the one below, and just the error message would differ.

Same for the freebsd version I suppose.

[rsc, 2011-02-09 18:02:23]

>
http://codereview.appspot.com/4148045/diff/7001/src/pkg/runtime/linux/mem.c#n...
> src/pkg/runtime/linux/mem.c:60: p = runtime·mmap(v, n,
> PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANON|MAP_PRIVATE, -1, 0);
> Isn't it Missing MAP_FIXED here, since it's still not
> just a hint?  It looks like the mmap should be the same
> as the one below, and just the error message would differ.

If you omit MAP_FIXED it means "put the mapping there
if you can, or elsewhere if that's taken".

If you set MAP_FIXED it means "blow away whatever is there".

The new calls omit MAP_FIXED so that we can detect
the "someone else got there first" case.

Russ

[niemeyer, 2011-02-09 18:25:07]

> If you omit MAP_FIXED it means "put the mapping there
> if you can, or elsewhere if that's taken".

I see, thanks.  I had the behavior of MAP_FIXED when
facing existing pages wrong.

[r, 2011-02-09 18:43:59]

LGTM but please be more forthcoming in CL descriptions of important changes.
what is the "new strategy"?  details make the history more easily comprehended.

[rsc, 2011-02-09 19:38:36]

*** Submitted as 770fc1179efc ***

runtime: new allocation strategy for amd64

Do not reserve virtual address space.
Instead, assume it will be there when we need it,
and crash loudly if that assumption is violated.
Reserving the address space gets charged to
ulimit -v, which exceeds commonly set limits.

http://groups.google.com/group/golang-dev/msg/7c477af5f5a8dd2c

R=r, niemeyer
CC=golang-dev
http://codereview.appspot.com/4148045