runtime: make max heap size configurable

[owenthereal]

I'm looking for a way to limit the max memory consumption of a Go program, say the memory doesn't exceed X. Further discussion is here.

Does it make sense to make runtime.MaxMem configurable?

1. What version of Go are you using (go version)?
   1.4.1.
2. What operating system and processor architecture are you using?
   64 bit Linux.
3. What did you do?
   I tried to limit the memory usage of my Go program. The server only has 1GB. The Go process was killed by the monitor process and the server was restarted.
4. What did you expect to see?
   I expect there's a variable in Go runtime to set this limit, e.g., runtime.MaxMem = x.
5. What did you see instead?
   I couldn't find a way to limit memory usage in Go. ulimit may be one option but it's not cross platform. Also ulimit requires root access and I don't have it since the server is hosted on Heroku.

/cc @davecheney

[bradfitz]

The issue tracker isn't a support forum. Please move this to golang-nuts@ or StackOverflow.

The answer will probably be ulimit.

[owenthereal]

The issue tracker isn't a support forum. Please move this to golang-nuts@ or StackOverflow.

This is not a supporting question. It's a feature request...

[owenthereal]

And ulimit is not cross platform...

[bradfitz]

Fair enough, I suppose. Although I'm not sure how much Go should try to be your operating system, as opposed to just recognizing and respecting the limits you've put on the process in your operating system. Will reopen.

[c4milo]

@bradfitz I think it would be worth writing a CONTRIBUTING guide here in GitHub so that its link shows up every time anybody is about to create a new issue. https://github.com/blog/1184-contributing-guidelines

[bradfitz]

@c4milo, we already did: https://github.com/golang/go/blob/master/CONTRIBUTING.md

[c4milo]

Clueless me. Sorry.

[owenthereal]

I added more description. However, I don't think the confusion was caused by not having filled the issue template.

[bradfitz]

Actually the issue is much better now, thanks.

[bradfitz]

See also: #5049 (runtime: respect memory ulimit more precisely).

[RLH]

Adding knobs like this can certainly seem attractive but they come with costs in the development cycle. A simple binary knob doubles the number of tests that the Go runtime team has to run. We run those tests a dozen times a day and leave them running every night when we go home. Each CL runs them across more than a dozen HW/OS configurations. This request suggests a non-binary knob where reasonable testing will require more than two values which is even worse. The bar to adding knobs in Go is, and should be, very high.
It's worse for the application programmer who now turns knobs all day instead of dealing with reducing the amount of live data which in turn will reduce the size of the heap. The GC will try to keep total heap size at about 2X live heap which is what the runtime team is tuning for.

[rsc]

Duplicate of #5049