runtime: add FreeOSMemory().

runtime: add FreeOSMemory().

Fixes issue 4171.
Update issue 4090.

[Sebastien Paolacci, 2012-12-22 15:20:59]

PTAL.

It is supposed to be applied on top of 7002049, but codereview insists for
grabbing both of them into that CL.

Russ suggested in 4190 to have that new call in runtime/debug, however
   - writing `debug.FreeOSMemory()' looks rather strange (to me), but I don't
have a strong opinion here.
   - I can't get goc2c to generate the method into the correct `runtime/debug'
namespace (and I don't feel like adding runtime/debug into the bootstrap
sequence desirable).

A side purpose is obviously to test 7002049.

Sebastien

[minux1, 2012-12-22 15:28:44]

On 2012/12/22 15:20:59, Sebastien Paolacci wrote:
> It is supposed to be applied on top of 7002049, but codereview insists for
> grabbing both of them into that CL.
You can wait until that CL is submitted and then mail this CL.
(mailing two CLs with dependencies is possible but is very
error-prone.)

[minux1, 2012-12-22 15:31:41]

https://codereview.appspot.com/7009044/diff/4005/api/next.txt
File api/next.txt (right):

https://codereview.appspot.com/7009044/diff/4005/api/next.txt#newcode345
api/next.txt:345: pkg runtime, func FreeOSMemory()
please don't change api/next.txt in this CL.

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

https://codereview.appspot.com/7009044/diff/4005/src/pkg/runtime/malloc.goc#n...
src/pkg/runtime/malloc.goc:785: env = runtime·getenv("GOGCTRACE");
why use this?
there are too many duplicated code using $GOGCTRACE env var.
I suggest we consolidate them into one.

[rsc, 2013-01-02 22:51:13]

please drop (). from CL description

https://codereview.appspot.com/7009044/diff/3005/api/next.txt
File api/next.txt (right):

https://codereview.appspot.com/7009044/diff/3005/api/next.txt#newcode345
api/next.txt:345: pkg runtime, func FreeOSMemory()
Please do not update api/next.txt except in CLs that do nothing else.
Otherwise we get merge conflicts when we have to cherrypick CLs into 
the release branch. You can revert this file for now.

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mgc0.c
File src/pkg/runtime/mgc0.c (left):

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mgc0.c#oldcode1
src/pkg/runtime/mgc0.c:1: // Copyright 2009 The Go Authors. All rights reserved.
Why did you delete this copyright notice?
Please put it back (and keep the 2009).

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mheap.c
File src/pkg/runtime/mheap.c (right):

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mheap.c#newc...
src/pkg/runtime/mheap.c:363: uint64 tick, gcgrace, spangrace;
gcgrace looks like gcg-race. Please use something like gctime and spantime if
you need to rename the variables.

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mheap.c#newc...
src/pkg/runtime/mheap.c:412: runtime·printf("scvg(%d): GC forced\n", seqid);
See other CL. Please keep using the existing format instead of making
unnecessary print statement changes. scvg%d is fine.

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mheap.c#newc...
src/pkg/runtime/mheap.c:438: runtime·printf("scvg(%d): %D MB released\n", seqid,
sumreleased>>20);
Same as in other CL: please preserve the old print statements.

[dvyukov, 2013-01-03 09:52:44]

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mheap.c
File src/pkg/runtime/mheap.c (right):

https://codereview.appspot.com/7009044/diff/3005/src/pkg/runtime/mheap.c#newc...
src/pkg/runtime/mheap.c:334: s->npreleased = t->npreleased;
Is this change correct if we coalesce with both previous and next spans?

[Sebastien Paolacci, 2013-01-06 09:38:03]

On 2012/12/22 15:28:44, minux wrote:
> On 2012/12/22 15:20:59, Sebastien Paolacci wrote:
> > It is supposed to be applied on top of 7002049, but codereview insists for
> > grabbing both of them into that CL.
> You can wait until that CL is submitted and then mail this CL.
> (mailing two CLs with dependencies is possible but is very
> error-prone.)

You're right, this CL is indeed a mess. I apologize for that.

Please hold until 7002049 is submitted, I'll rebase/fix then.

Thanks,
Sebastien