mheap.map become a pointer, so nelem(h->map) returns 1 rather than the map size.
As the result coalescing with subsequent spans does not happen.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/9649046

It is a caching wrapper around SysAlloc() that can allocate small chunks.
Use it for symtab allocations. Reduces number of symtab walks from 4 to 3
(reduces buildfuncs time from 10ms to 7.5ms on a large binary,
reduces initial heap size by 680K on the same binary).
Also can be used for type info allocation, itab allocation.
There are also several places in GC where we do the same thing,
they can be changed to use persistentalloc().
Also can be used in FixAlloc, because each instance of FixAlloc allocates
in 128K regions, which is too eager.
Reincarnation of committed and rolled back https://golang.org/cl/9805043
The latent bugs that it revealed are fixed:
https://golang.org/cl/9837049
https://golang.org/cl/9778048

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/9778049

Then use the limit to make sure MHeap_LookupMaybe & inlined
copies don't return a span if the pointer is beyond the limit.
Use this fact to optimize all call sites.

R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/9869045

R=golang-dev, khr, rsc
CC=golang-dev
https://golang.org/cl/9728045

As the code now says:

We are forced to return a float64 because the API is silly, but do
the division as integers so we can ask if AllocsPerRun()==1
instead of AllocsPerRun()<2.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/9837049

as was dicussed in cl/9791044

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9853046

Required for preemptive scheduler, see the comment.

R=golang-dev, daniel.morsing
CC=golang-dev
https://golang.org/cl/9841047

Escape analysis already gives that the underlying array
does not escape but the result was ignored.

Fixes #5484.

R=golang-dev, dave, daniel.morsing
CC=golang-dev
https://golang.org/cl/9662046

Fixes #5591.

R=golang-dev, dave, minux.ma, cshapiro
CC=carl shapiro <cshapiro, golang-dev
https://golang.org/cl/9839046

Fixes #5405.

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/9856043

A nosplits was assumed to have no argument information and no
pointer map.  However, nosplits created by the linker often
have both.  This change uses the pointer map size as an
alternate source of argument size when processing a nosplit.

In addition, the symbol table construction pointer map size
and argument size consistency check is strengthened.  If a
nptrs is greater than 0 it must be equal to the number of
argument words.

R=golang-dev, khr, khr
CC=golang-dev
https://golang.org/cl/9666047

to avoid unintentionally clobber R9/R10.
Thanks Lucio for the suggestion.

PS: yes, this could be considered a big change (but not an API change), but
as it turns out even temporarily changes R9/R10 in user code is unsafe and
leads to very hard to diagnose problems later, better to disable using R9/R10
when the user first uses it.
See CL 6300043 and CL 6305100 for two problems caused by misusing R9/R10.

R=golang-dev, khr, rsc
CC=golang-dev
https://golang.org/cl/9840043

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/9826043

R=golang-dev, dave, iant
CC=golang-dev
https://golang.org/cl/9738045

R=iant
CC=golang-dev
https://golang.org/cl/9738046

The old code put the index before the period in the precision;
it should be after so it's always before the star, as documented.
A little trickier to do in one pass but compensated for by more
tests and catching a couple of other error cases.

R=rsc
CC=golang-dev
https://golang.org/cl/9751044

Currently we only check the leaf node's issuer against the list of
distinguished names in the server's CertificateRequest message. This
will fail if the client certiciate has more than one certificate in
the path and the leaf node issuer isn't in the list of distinguished
names, but the issuer's issuer was in the distinguished names.

R=agl, agl
CC=gobot, golang-dev
https://golang.org/cl/9795043

Generated by addca.

R=gobot
CC=golang-dev
https://golang.org/cl/9798049

This is needed for preemptive scheduler, because during
stoptheworld we want to wait with timeout and re-preempt
M's on timeout.

R=golang-dev, remyoudompheng, iant
CC=golang-dev
https://golang.org/cl/9375043

See https://en.wikipedia.org/wiki/Newton%27s_method#Square_root_of_a_number

R=golang-dev, minux.ma, adg
CC=golang-dev
https://golang.org/cl/9145044

R=golang-dev
CC=golang-dev
https://golang.org/cl/9853043

With this change the compiler emits a bitmap for each function
covering its stack frame arguments area.  If an argument word
is known to contain a pointer, a bit is set.  The garbage
collector reads this information when scanning the stack by
frames and uses it to ignores locations known to not contain a
pointer.

R=golang-dev, bradfitz, daniel.morsing, dvyukov, khr, khr, iant, cshapiro
CC=golang-dev
https://golang.org/cl/9223046

This depends on: 9791044: runtime: allocate page table lazily
Once page table is moved out of heap, the heap becomes small.
This removes unnecessary dereferences during heap access.
No logical changes.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/9802043

This removes the 256MB memory allocation at startup,
which conflicts with ulimit.
Also will allow to eliminate an unnecessary memory dereference in GC,
because the page table is usually mapped at known address.
Update #5049.
Update #5236.

R=golang-dev, khr, r, khr, rsc
CC=golang-dev
https://golang.org/cl/9791044

we need it for GC anyway.

R=golang-dev, khr, dave, khr
CC=golang-dev
https://golang.org/cl/9728044

Currently the test closes random files descriptors,
which leads to hang (in particular if netpoll fd is closed).
Try to open only fd 3, since the parent process expects it to be fd 3 anyway.
Fixes #5571.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9778048

The 'n' variable is used during rescan initiation in GC_END case,
but it's overwritten with chan capacity in GC_CHAN case.
As the result rescan is done with the wrong object size.
Fixes #5554.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/9831043

also don't clobber R9 if it is about to crash.

In response to https://golang.org/cl/9251043/#msg2.

R=golang-dev, khr, khr, dave
CC=golang-dev
https://golang.org/cl/9778046

multiple failures on amd64

««« original CL description
runtime: introduce helper persistentalloc() function
It is a caching wrapper around SysAlloc() that can allocate small chunks.
Use it for symtab allocations. Reduces number of symtab walks from 4 to 3
(reduces buildfuncs time from 10ms to 7.5ms on a large binary,
reduces initial heap size by 680K on the same binary).
Also can be used for type info allocation, itab allocation.
There are also several places in GC where we do the same thing,
they can be changed to use persistentalloc().
Also can be used in FixAlloc, because each instance of FixAlloc allocates
in 128K regions, which is too eager.

R=golang-dev, daniel.morsing, khr
CC=golang-dev
https://golang.org/cl/9805043
»»»

R=golang-dev
CC=golang-dev
https://golang.org/cl/9822043

benchmark                    old ns/op    new ns/op    delta
BenchmarkMalloc8                    68           62   -8.63%
BenchmarkMalloc16                   75           69   -7.94%
BenchmarkMallocTypeInfo8           102           98   -3.73%
BenchmarkMallocTypeInfo16          108          103   -4.63%

R=golang-dev, dave, khr
CC=golang-dev
https://golang.org/cl/9790043

It is a caching wrapper around SysAlloc() that can allocate small chunks.
Use it for symtab allocations. Reduces number of symtab walks from 4 to 3
(reduces buildfuncs time from 10ms to 7.5ms on a large binary,
reduces initial heap size by 680K on the same binary).
Also can be used for type info allocation, itab allocation.
There are also several places in GC where we do the same thing,
they can be changed to use persistentalloc().
Also can be used in FixAlloc, because each instance of FixAlloc allocates
in 128K regions, which is too eager.

R=golang-dev, daniel.morsing, khr
CC=golang-dev
https://golang.org/cl/9805043

R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/9808043

In preparation for CL 9249043 (already submitted).

Fixes #5553.

R=golang-dev, iant, capnm9, dave
CC=golang-dev
https://golang.org/cl/9251043

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/9648044

Variables in data sections of 32-bit executables interfere with
garbage collector's ability to free objects and/or unnecessarily
slow down the garbage collector.

This changeset moves some static variables to .noptr sections.
'files' in symtab.c is now allocated dynamically.

R=golang-dev, dvyukov, minux.ma
CC=golang-dev
https://golang.org/cl/9786044

This fixes two intra-page "type assertion" links that were broken in
different ways.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/9797043

Generated by addca.

R=gobot
CC=golang-dev
https://golang.org/cl/9797044

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9665046

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/9574043

This text is added to doc.go:

        Explicit argument indexes:

        In Printf, Sprintf, and Fprintf, the default behavior is for each
        formatting verb to format successive arguments passed in the call.
        However, the notation [n] immediately before the verb indicates that the
        nth one-indexed argument is to be formatted instead. The same notation
        before a '*' for a width or precision selects the argument index holding
        the value. After processing a bracketed expression [n], arguments n+1,
        n+2, etc. will be processed unless otherwise directed.

        For example,
                fmt.Sprintf("%[2]d %[1]d\n", 11, 22)
        will yield "22, 11", while
                fmt.Sprintf("%[3]*[2].*[1]f", 12.0, 2, 6),
        equivalent to
                fmt.Sprintf("%6.2f", 12.0),
        will yield " 12.00". Because an explicit index affects subsequent verbs,
        this notation can be used to print the same values multiple times
        by resetting the index for the first argument to be repeated:
                fmt.Sprintf("%d %d %#[1]x %#x", 16, 17)
        will yield "16 17 0x10 0x11".

The notation chosen differs from that in C, but I believe it's easier to read
and to remember (we're indexing the arguments), and compatibility with
C's printf was never a strong goal anyway.

While we're here, change the word "field" to "arg" or "argument" in the
code; it was being misused and was confusing.

R=rsc, bradfitz, rogpeppe, minux.ma, peter.armitage
CC=golang-dev
https://golang.org/cl/9680043