It's sad to introduce a new macro, but rnd shows up consistently
in profiles, and the function call overwhelms the two arithmetic
instructions it performs.
R=r
CC=golang-dev
https://golang.org/cl/6260051
This is from CL 5451105 but was dropped from that CL.
See also CL 6137051.
The only change compared to 5451105 is to check for
h != nil in reflect·mapiterinit; allowing use of nil maps
must have happened after that original CL.
Fixes#3573.
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/6215078
The previous attempt to explain this got it backwards (all the more reason to be
sad we couldn't make the two functions behave the same).
Fixes#3669.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6249051
This fixes occasional 64-bit failures.
Maybe it will fix the 32-bit failures too,
so re-enable on 32-bit for now.
R=golang-dev, bradfitz, r, dvyukov
CC=golang-dev
https://golang.org/cl/6218050
With the timed semacquire patch
(kernel-tsemacquire) for Plan 9,
we can now properly do a timed
wait for the semaphore, in
semasleep.
R=golang-dev, rsc, rminnich, ality, r
CC=0intro, golang-dev, john, mirtchovski
https://golang.org/cl/6197046
Implement getcontext and sigprocmask for NetBSD - these will soon be
used by the thread handling code.
Also fix netbsd/386 signal handling - there is no sigreturn, just
return so that we hit the trampoline.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6215049
Update/correct NetBSD signal handling - most of this is needed due to
the correctly generated runtime definitions.
R=golang-dev, m4dh4tt3r, rsc
CC=golang-dev
https://golang.org/cl/6195079
Fix and regenerate runtime defs for NetBSD.
Whilst the mcontext struct can be handled across architectures,
the registers are provided as defines that index an array, rather
than as members of the struct. Since these are architecture
dependent, include them via a defs_netbsd_<arch>.go file.
R=golang-dev, m4dh4tt3r, rsc
CC=golang-dev
https://golang.org/cl/6190070
Parallel GC needs to know in advance how many helper threads will be there.
Hopefully it's the last patch before I can tackle parallel sweep phase.
The benchmarks are unaffected.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6200064
Set the TLS base using the _lwp_setprivate() syscall, instead of via
sysarch(). NetBSD tracks the pointer passed to _lwp_setprivate() and
restores this value when restoring mcontext. If sysarch() is used
directly, restoring an mcontext trashes the FS/GS value, resulting
in a segfault when we next try to access the TLS.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6206062
we can't add the division result to n during iteration, because it might
turn n into NaN or Inf.
R=golang-dev, rsc, iant, iant
CC=golang-dev
https://golang.org/cl/6197045
Use correct syscall numbers and arguments for NetBSD.
Provide a trampoline for signal returns (using signal API 3).
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6209048
Decode AT_RANDOM, AT_HWCAP, and AT_PLATFORM.
This CL only make use of AT_RANDOM, but future CLs will make use of the others.
R=dave, rsc
CC=golang-dev
https://golang.org/cl/5978051
1. In CL 5989057, I made a mistake in the last minute change.
"MOVW.W R4, -4(SP)" should really be "MOVW.W R4, -4(R13)",
as 5l will rewrite offset for SP.
2. misc/cgo/test/issue1560.go tests for parallel sleep of 1s,
but on ARM, the deadline is frequently missed, so change sleep
time to 2s on ARM.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6202043
This adds proper note handling for Plan 9,
and fixes the issue of properly killing go procs.
Without this change, the first go proc that dies
(using runtime·exit()) would kill all the running
go procs. Proper signal handling is needed.
R=golang-dev, ality, rminnich, rsc
CC=golang-dev, john, mirtchovski
https://golang.org/cl/5617048
This makes it possible to inline the prefetch of upcoming
memory addresses during garbage collection, instead of
needing to flush registers, make a function call, and
reload registers. On garbage collection-heavy workloads,
this results in a 5% speedup.
Fixes#3493.
R=dvyukov, ken, r, dave
CC=golang-dev
https://golang.org/cl/5990066
Switch from using the rfork() syscall on OpenBSD, to the __tfork()
syscall. The __tfork() syscall is the preferred way of creating
system threads and the rfork() syscall has recently been removed.
Note: this will break compatibility with OpenBSD releases prior to 5.1.
R=golang-dev, bradfitz, devon.odell, rsc
CC=golang-dev
https://golang.org/cl/6037048
This lets the test pass on PPC64 GNU/Linux, which uses a much
larger page size and thus uses more memory to hold blocks
allocated for memory profiling.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6048054
Update runtime defs for openbsd. Add struct __tfork, which will be
needed by an upcoming change.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/6007050
Update the threxit and thrsleep syscalls to match the ABI of the
OpenBSD 5.1 kernel. These changes are backwards compatible with
older kernels.
Fixes#3311.
R=golang-dev, rsc, devon.odell
CC=golang-dev
https://golang.org/cl/5777079
This leads to ~30kB improvement on code size for ARM machines with VFP/NEON.
Example: go test -c math
GOARM=5 GOARM=6
Old: 1884200 1839144
New: 1884165 1805245
-: 35 33899
R=rsc, bradfitz, dave, kai.backman
CC=golang-dev
https://golang.org/cl/5975060
Change 5660047 moved an FLDCW instruction
that disables invalid operand traps into
runtime·asminit, which is called from
runtime·mstart. Thus, runtime·check is being
called prior to setting the appropriate control bits,
which on any QNaN comparison will cause Plan 9
to take an invalid operand trap. This change loads
the control bits (for Plan 9) prior to runtime·check.
Ideally, this should be done before the QNaN checks
on any system, but possibly other kernels simply
don't ever trap on invalid operands.
R=golang-dev, rminnich
CC=golang-dev, john, rsc
https://golang.org/cl/5939045
Block signals during thread creation, otherwise the new thread can
receive a signal prior to initialisation completing.
Fixes#3102.
R=golang-dev, rsc, devon.odell, minux.ma
CC=golang-dev
https://golang.org/cl/5757064
It is a bug that Caller and Callers disagree about the offset of the skip
parameter. Document the bug.
R=rsc, dsymonds, r, iant
CC=golang-dev
https://golang.org/cl/5976064
Not a complete fix for issue 3342, but fixes the trivial case.
There may still be a race in the instants before and after
a scavenger-induced garbage collection.
Intended to be "obviously safe": a call to runtime·gosched
before main.main is no different than a call to runtime.Gosched
at the beginning of main.main, and it is (or had better be)
safe to call runtime.Gosched at any point during main.
Update #3342.
R=iant
CC=golang-dev
https://golang.org/cl/5919052
Breaks closure test when GOMAXPROCS=2 or more.
««« original CL description
runtime: restore deadlock detection in the simplest case.
Fixes#3342.
R=iant, r, dave, rsc
CC=golang-dev, remy
https://golang.org/cl/5844051
»»»
R=rsc
CC=golang-dev
https://golang.org/cl/5924045
There was a small window during program initialization
where a signal could come in before the handling mechanisms
were set up to handle it. Delay the signal-handler installation
until we're ready for the signals.
Fixes#3314.
R=golang-dev, dsymonds, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5833049
This function uses 48-byte of precious non-split stack for every callback
function, and without this CL, it can easily overflow the non-split stack.
I encountered this when trying to enable misc/cgo/test on windows/amd64.
R=rsc
CC=golang-dev
https://golang.org/cl/5784075
It's the best we can do before Go 1.
For issue 3250; not a fix but at least less mysterious.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5797068
It may have to switch stacks, since we are calling
a DLL instead of a system call.
badcallback says where it is, because it is being called
on a Windows stack already.
R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/5782060
Implement runtime·write, like on the other systems,
and also runtime·badcallback, in assembly to reduce
stack footprint.
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/5785055
When a very low-level system call that should never fail
does fail, we call notok, which crashes the program.
Often, we are then left with only the program counter as
information about the crash, and it is in notok.
Instead, inline calls to notok (it is just one instruction
on most systems) so that the program counter will
tell us which system call is unhappy.
R=golang-dev, gri, minux.ma, bradfitz
CC=golang-dev
https://golang.org/cl/5792048
Before:
$ go run x.go
signal 11 (core dumped)
$
After:
$ go run x.go
runtime: cgo callback on thread not created by Go.
signal 11 (core dumped)
$
For issue 3068.
Not a fix, but as much of a fix as we can do before Go 1.
R=golang-dev, rogpeppe, gri
CC=golang-dev
https://golang.org/cl/5781047
If it didn't reach the limit, we can try extending the arena
before resorting to random memory mappings and praying for the
kernel to be kind.
Fixes#3173.
R=rsc, rsc
CC=golang-dev
https://golang.org/cl/5725045
Don't try to print obviously corrupt slices or interfaces.
Doesn't actually solve 3047 or 2818, but seems a good idea anyway.
R=rsc, bsiegert
CC=golang-dev
https://golang.org/cl/5708061
Work around profiling kernel bug with signal masks.
Still broken on 64-bit Snow Leopard kernel,
but I think we can ignore that one and let people
upgrade to Lion.
Add new trivial tools addr2line and objdump to take
the place of the GNU tools of the same name, since
those are not installed on OS X.
Adapt pprof to invoke 'go tool addr2line' and
'go tool objdump' if the system tools do not exist.
Clean up disassembly of base register on amd64.
Fixes#2008.
R=golang-dev, bradfitz, mikioh.mikioh, r, iant
CC=golang-dev
https://golang.org/cl/5697066
Makes it possible for client code to maintain its own profiles,
and also reduces the API surface by giving us a type that
models built-in profiles.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5684056
Ignore signals while we are spawning a new thread. Previously, a
signal arriving just before runtime.minit setting up the signal
handler triggers a "double fault" in signal trampolining.
Fixes#3017.
R=rsc, mikioh.mikioh, minux.ma, adg
CC=golang-dev
https://golang.org/cl/5684060
cc: add #pragma textflag to set it
runtime: mark mheap to go into noptr-bss.
remove special case in garbage collector
Remove the ARM from.flag field created by CL 5687044.
The DUPOK flag was already in p->reg, so keep using that.
Otherwise test/nilptr.go creates a very large binary.
Should fix the arm build.
Diagnosed by minux.ma; replacement for CL 5690044.
R=golang-dev, minux.ma, r
CC=golang-dev
https://golang.org/cl/5686060
A fault during malloc might lead to the program's
first call to findfunc, which would in turn call malloc.
Don't do that.
Fixes#1777.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5689047
morebuf holds a pc/sp from the last stack split or
reflect.call or panic/recover. If the pc is a closure,
the reference will keep it from being collected.
moreargp holds a pointer to the arguments from the
last stack split or reflect.call or panic/recover.
Normally it is a stack pointer and thus not of interest,
but in the case of reflect.call it is an allocated argument
list and holds up the arguments to the call.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5674109
The m->cret word holds the C return value when returning
across a stack split boundary. It was not being cleared after
use, which means that the return value (if a C function)
or else the value of AX/R0 at the time of the last stack unsplit
was being kept alive longer than necessary. Clear it.
I think the effect here should be very small, but worth fixing
anyway.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5677092
Periodically browse MHeap's freelists for long unused spans and release them if any.
Current hardcoded settings:
- GC is forced if none occured over the last 2 minutes.
- spans are handed back after 5 minutes of uselessness.
SysUnused (for Unix) is a wrapper on madvise MADV_DONTNEED on Linux and MADV_FREE on BSDs.
R=rsc, dvyukov, remyoudompheng
CC=golang-dev
https://golang.org/cl/5451057
Changeset 36c9c7810f14 broke support for grsec-patched kernels.
Those do not give back the address requested without MAP_FIXED,
so when verifying an mmap without this flag for success, the
resulting address must not be compared against the requested
address since it may have succeeded at a different location.
R=golang-dev, rsc, gustavo, iant
CC=golang-dev
https://golang.org/cl/5650072
before after
go test -short time 4.144s 1.215s
go test -short runtime 1.315s 0.351s
go test -short -cpu=1,2,4 runtime 4.376s 1.266s
Partially solves issue 3015.
R=golang-dev, r
CC=golang-dev, remy
https://golang.org/cl/5673045
It is possible that Linux and Windows copy the FP control word
from the parent thread when creating a new thread. Empirically,
Darwin does not. Reset the FP control world in all cases.
Enable the floating-point strconv test.
Fixes#2917 (again).
R=golang-dev, r, iant
CC=golang-dev
https://golang.org/cl/5660047
It's not as pretty, but it deletes some irrelevant information from the
printout and avoids a dependency.
It also means the test binary will stop if a test panics. That's a feature,
not a bug.
Any output printed by the test appears before the panic traceback.
before:
--- FAIL: TestPanic (0.00 seconds)
fmt_test.go:19: HI
testing.go:257: runtime error: index out of range
/Users/r/go/src/pkg/testing/testing.go:257 (0x23998)
_func_003: t.Logf("%s\n%s", err, debug.Stack())
/Users/r/go/src/pkg/runtime/proc.c:1388 (0x10d2d)
panic: reflect·call(d->fn, d->args, d->siz);
/Users/r/go/src/pkg/runtime/runtime.c:128 (0x119b0)
panicstring: runtime·panic(err);
/Users/r/go/src/pkg/runtime/runtime.c:85 (0x11857)
panicindex: runtime·panicstring("index out of range");
/Users/r/go/src/pkg/fmt/fmt_test.go:21 (0x23d72)
TestPanic: a[10]=1
/Users/r/go/src/pkg/testing/testing.go:264 (0x21b75)
tRunner: test.F(t)
/Users/r/go/src/pkg/runtime/proc.c:258 (0xee9e)
goexit: runtime·goexit(void)
FAIL
after:
--- FAIL: TestPanic (0.00 seconds)
fmt_test.go:19: HI
panic: runtime error: index out of range [recovered]
panic: (*testing.T) (0xec3b0,0xf8400001c0)
goroutine 2 [running]:
testing._func_003(0x21f5fa8, 0x21f5100, 0x21f5fb8, 0x21f5e88)
/Users/r/go/src/pkg/testing/testing.go:259 +0x108
----- stack segment boundary -----
fmt_test.TestPanic(0xf8400001c0, 0x27603728)
/Users/r/go/src/pkg/fmt/fmt_test.go:21 +0x6b
testing.tRunner(0xf8400001c0, 0x18edb8, 0x0, 0x0)
/Users/r/go/src/pkg/testing/testing.go:264 +0x6f
created by testing.RunTests
/Users/r/go/src/pkg/testing/testing.go:343 +0x76e
goroutine 1 [chan receive]:
testing.RunTests(0x2000, 0x18edb8, 0x2400000024, 0x100000001, 0x200000001, ...)
/Users/r/go/src/pkg/testing/testing.go:344 +0x791
testing.Main(0x2000, 0x18edb8, 0x2400000024, 0x188a58, 0x800000008, ...)
/Users/r/go/src/pkg/testing/testing.go:275 +0x62
main.main()
/var/folders/++/+++Fn+++6+0++4RjPqRgNE++2Qk/-Tmp-/go-build743922747/fmt/_test/_testmain.go:129 +0x91
exit status 2
R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/5658048
1, IMO, the fatal error "regfree: not a register" from 5g when
compiling runtime/debug.go is due to gcc miscompile, it doesn't
show up when compiled with -O0. But I still haven't thought of
a way to fix this, should all ARM builds be built with -O0?
2, fixed mksysnum_linux.pl, so zsysnum_linux_arm.go no longer
needs to be hand-generated.
3, regen all in pkg syscall for Linux/ARM on Debian 6.0
This CL is somewhat big, I'd like to split it if necessary.
R=rsc, dave
CC=golang-dev
https://golang.org/cl/5659044
Restore package os/signal, with new API:
Notify replaces Incoming, allowing clients
to ask for certain signals only. Also, signals
go to everyone who asks, not just one client.
This could plausibly move into package os now
that there are no magic side effects as a result
of the import.
Update runtime for new API: move common Unix
signal handling code into signal_unix.c.
(It's so easy to do this now that we don't have
to edit Makefiles!)
Tested on darwin,linux 386,amd64.
Fixes#1266.
R=r, dsymonds, bradfitz, iant, borman
CC=golang-dev
https://golang.org/cl/3749041
Among other things, this avoids putting a testing.go:nnn:
prefix on every line of the stack trace.
R=golang-dev, r, dsymonds, r
CC=golang-dev
https://golang.org/cl/5651081
unsafe: delete Typeof, Reflect, Unreflect, New, NewArray
Part of issue 2955 and issue 2968.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5650069
Otherwise lockorder may be misaligned, since lockorder is a
list of pointers and pollorder is a list of uint16.
Discovered running gccgo (which uses a modified copy of this
code) on SPARC.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5655054
If the values being compared have different concrete types,
then they're clearly unequal without needing to invoke the
actual interface compare routine. This speeds tests for
specific values, like if err == io.EOF, by about 3x.
benchmark old ns/op new ns/op delta
BenchmarkIfaceCmp100 843 287 -65.95%
BenchmarkIfaceCmpNil100 184 182 -1.09%
Fixes#2591.
R=ken2
CC=golang-dev
https://golang.org/cl/5651073
On 64 bit UML it is not possible to reserve memory at 0xF8<<32.
Detect when linux cannot use these high virtual memory addresses
and drop back to the 32 bit memory allocator.
R=rsc, cw
CC=golang-dev
https://golang.org/cl/5634050
Same idea as heap profile: how did each thread get created?
Low memory (256 bytes per OS thread), high reward for
programs that suddenly have many threads running.
Fixes#1477.
R=golang-dev, r, dvyukov
CC=golang-dev
https://golang.org/cl/5639059
Unexports runtime.MemStats and rename MemStatsType to MemStats.
The new accessor requires passing a pointer to a user-allocated
MemStats structure.
Fixes#2572.
R=bradfitz, rsc, bradfitz, gustavo
CC=golang-dev, remy
https://golang.org/cl/5616072
Multiplying by the low 32 bits was a bad idea
no matter what, but it was a particularly unfortunate
choice because those bits are 0 for small integer values.
Fixes#2883.
R=ken2
CC=golang-dev
https://golang.org/cl/5634047
Right now, GOTRACEBACK=0 means do not show any stack traces.
Unset means the default behavior (declutter by hiding runtime routines).
This CL makes GOTRACEBACK=2 mean include the runtime routines.
It avoids having to recompile the runtime when you want to see
the runtime in the tracebacks.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5633050
The go- is redundant now that the directory is required
to be inside $GOROOT. Rob LGTMed the idea.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5618044
This patch adds a function to get the current cpu ticks. This is
deemed to be 'sufficiently random' to use to seed fastrand to mitigate
the algorithmic complexity attacks on the hash table implementation.
On AMD64 we use the RDTSC instruction. For 386, this instruction,
while valid, is not recognized by 8a so I've inserted the opcode by
hand. For ARM, this routine is currently stubbed to return a constant
0 value.
Future work: update 8a to recognize RDTSC.
Fixes#2630.
R=rsc
CC=golang-dev
https://golang.org/cl/5606048
This patch adds a hash seed to the Hmap struct. Each seed is
initialized by runtime.fastrand1(). This is the first step of a
solution to issue 2630. Fastrand1 still needs to be updated to provide
us with actually random bits.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5599046
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
We weren't properly deleting the various header
files (that were temporarily renamed) if a $CC
for the current $GOARCH didn't exist. And since
the compiler checks the current directory for
headers before any -I arguments, this had the
unfortunate side effect of including the last
generated headers instead of the correct ones.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5581055
Also delete gotest, since it's messy to fix and slated for deletion anyway.
A couple of things outside src can't be tested any more. "go test" will be
fixed and these tests will be re-enabled. They're noisy for now.
Fixes#284.
R=rsc
CC=golang-dev
https://golang.org/cl/5598049
In order to allow buildscript.sh to generate buildscripts for all
$GOOS/$GOARCH combinations, we have to generate dummy files for cmd/go.
Fixes#2586.
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5557050
- use proper Win64 gcc calling convention when
calling initcgo on amd64
- increase g0 stack size to 64K on amd64 to make
it the same as 386
- implement C.sleep
- do not use C.stat, since it is renamed to C._stat by mingw
- use fopen to implement TestErrno, since C.strtol
always succeeds on windows
- skip TestSetEnv on windows, because os.Setenv
sets windows process environment, while C.getenv
inspects internal C runtime variable instead
R=golang-dev, vcc.163, rsc
CC=golang-dev
https://golang.org/cl/5500094
pkg/runtime/sys_darwin_amd64.s: fixes syscall select nr
pkg/runtime/sys_linux_arm.s: uses newselect instead of the now unimplemented
(old) select, also fixes the wrong div/mod statements in runtime.usleep.
Fixes#2633
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5504096
If something goes wrong, it should suffice to set
USE_GO_TOOL=false in env.bash to fall back to the
makefiles. I will delete the makefiles in January.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5502047
Also rename -v to -x in the build and install commands,
to match the flag in go test (which we can't change
because -v is taken). Matches sh -x anyway.
R=r, iant, ality
CC=golang-dev
https://golang.org/cl/5504045
This is like the ill-fated CL 5493063 except that
I have written a shell script (autogen.sh) instead of
thinking I could possibly write a correct Makefile.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5496075
That was the last build that was close to working.
I will try that change again next week.
Make is being very subtle today.
At the reverted-to CL, the ARM traceback appears
to be broken. I'll look into that next week too.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5492063
Why it was not failing anywhere else I don't know,
but the Makefile was definitely wrong. The rules
must not run in parallel.
TBR=r
CC=golang-dev
https://golang.org/cl/5489069
I am looking forward to not supporting two build
systems simultaneously. Make complains about
a circular dependency still, but I don't understand it
and it's probably not worth the time to figure out.
TBR=r
CC=golang-dev
https://golang.org/cl/5496058
Collapse the arch,os-specific directories into the main directory
by renaming xxx/foo.c to foo_xxx.c, and so on.
There are no substantial edits here, except to the Makefile.
The assumption is that the Go tool will #define GOOS_darwin
and GOARCH_amd64 and will make any file named something
like signals_darwin.h available as signals_GOOS.h during the
build. This replaces what used to be done with -I$(GOOS).
There is still work to be done to make runtime build with
standard tools, but this is a big step. After this we will have
to write a script to generate all the generated files so they
can be checked in (instead of generated during the build).
R=r, iant, r, lucio.dere
CC=golang-dev
https://golang.org/cl/5490053
Testing total space fails for gccgo when not using split
stacks, because then each goroutine has a large stack, and so
the total memory usage is large.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5487068
This will be nicer to the automatic tools.
It requires a few more assembly stubs
but fewer Go files.
There are a few instances where it looks like
there are new blobs of code, but they are just
being copied out of deleted files.
There is no new code here.
Suppose you have a portable implementation for Sin
and a 386-specific assembly one. The old way to
do this was to write three files
sin_decl.go
func Sin(x float64) float64 // declaration only
sin_386.s
assembly implementation
sin_port.go
func Sin(x float64) float64 { ... } // pure-Go impl
and then link in either sin_decl.go+sin_386.s or
just sin_port.go. The Makefile actually did the magic
of linking in only the _port.go files for those without
assembly and only the _decl.go files for those with
assembly, or at least some of that magic.
The biggest problem with this, beyond being hard
to explain to the build system, is that once you do
explain it to the build system, godoc knows which
of sin_port.go or sin_decl.go are involved on a given
architecture, and it (correctly) ignores the other.
That means you have to put identical doc comments
in both files.
The new approach, which is more like what we did
in the later packages math/big and sync/atomic,
is to have
sin.go
func Sin(x float64) float64 // decl only
func sin(x float64) float64 {...} // pure-Go impl
sin_386.s
// assembly for Sin (ignores sin)
sin_amd64.s
// assembly for Sin: jmp sin
sin_arm.s
// assembly for Sin: jmp sin
Once we abandon Makefiles we can put all the assembly
stubs in one source file, so the number of files will
actually go down.
Chris asked whether the branches cost anything.
Given that they are branching to pure-Go implementations
that are not typically known for their speed, the single
direct branch is not going to be noticeable. That is,
it's on the slow path.
An alternative would have been to preserve the old
"only write assembly files when there's an implementation"
and still have just one copy of the declaration of Sin
(and thus one doc comment) by doing:
sin.go
func Sin(x float64) float64 { return sin(x) }
sin_decl.go
func sin(x float64) float64 // declaration only
sin_386.s
// assembly for sin
sin_port.go
func sin(x float64) float64 { portable code }
In this version everyone would link in sin.go and
then either sin_decl.go+sin_386.s or sin_port.go.
This has an extra function call on all paths, including
the "fast path" to get to assembly, and it triples the
number of Go files involved compared to what I did
in this CL. On the other hand you don't have to
write assembly stubs. After starting down this path
I decided that the assembly stubs were the easier
approach.
As for generating the assembly stubs on the fly, much
of the goal here is to eliminate magic from the build
process, so that zero-configuration tools like goinstall
or the new go tool can handle this package.
R=golang-dev, r, cw, iant, r
CC=golang-dev
https://golang.org/cl/5488057
To allow these types as map keys, we must fill in
equal and hash functions in their algorithm tables.
Structs or arrays that are "just memory", like [2]int,
can and do continue to use the AMEM algorithm.
Structs or arrays that contain special values like
strings or interface values use generated functions
for both equal and hash.
The runtime helper func runtime.equal(t, x, y) bool handles
the general equality case for x == y and calls out to
the equal implementation in the algorithm table.
For short values (<= 4 struct fields or array elements),
the sequence of elementwise comparisons is inlined
instead of calling runtime.equal.
R=ken, mpimenov
CC=golang-dev
https://golang.org/cl/5451105
I had to move readFile into sys_$GOOS.go
since syscall.Open takes only two arguments
on Plan 9.
R=lucio.dere, rsc, alex.brainman
CC=golang-dev
https://golang.org/cl/5447061
Equality on structs will require arbitrary code for type equality,
so change algorithm in type data from uint8 to table pointer.
In the process, trim top-level map structure from
104/80 bytes (64-bit/32-bit) to 24/12.
Equality on structs will require being able to call code generated
by the Go compiler, and C code has no way to access Go return
values, so change the hash and equal algorithm functions to take
a pointer to a result instead of returning the result.
R=ken
CC=golang-dev
https://golang.org/cl/5453043
The environment is needed by package time, which
we want not to depend on os (so that os can use
time.Time), so push down into syscall.
Delete syscall.Sleep, now unnecessary.
The package os environment API is preserved;
it is only the implementation that is moving to syscall.
Delete os.Envs, which was undocumented,
uninitialized on Windows and Plan 9, and
not maintained by Setenv and Clearenv.
Code can call os.Environ instead.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5370091
The timespec passed to thrsleep() needs to be an absolute/realtime
value, so add the current nanotime to ns.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5374048
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes#1644.
Fixes#1731.
Fixes#2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
Fixes crash when cgo consumes more than 8K
of stack and makes a callback.
Fixes#1328.
R=golang-dev, rogpeppe, rsc
CC=golang-dev, mpimenov
https://golang.org/cl/5371042
Otherwise some OS X toolchains complain about the redeclaration
of libcgo_thread_start by multiple object files. The real definition
is in util.c.
Fixes#2167.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5364045
- Fix function prototype for thrsleep().
- Provide enums for clock identifiers.
- Provide timespec structure for use with thrsleep().
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5360042
runtime knows how to get the time of day
without allocating memory.
R=golang-dev, dsymonds, dave, hectorchu, r, cw
CC=golang-dev
https://golang.org/cl/5297078
We only guarantee that the main goroutine runs on the
main OS thread for initialization. Programs that wish to
preserve that property for main.main can call runtime.LockOSThread.
This is what programs used to do before we unleashed
goroutines during init, so it is both a simple fix and keeps
existing programs working.
R=iant, r, dave, dvyukov
CC=golang-dev
https://golang.org/cl/5309070
Revert workaround in compiler and
revert test for compiler workaround.
Tested that the 386 build continues to fail if
the gc change is made without the reflect change.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5312041
The old m[x] = 0, false syntax will be deleted
in a month or so, once people have had time to
change their code (there is a gofix in a separate CL).
R=ken2
CC=golang-dev
https://golang.org/cl/5265048
New DLL and Proc types to manage and call dll functions. These were
used to simplify syscall tests in runtime package. They were also
used to implement LazyDLL and LazyProc.
LazyProc, like Proc, now have Call function, that just a wrapper for
SyscallN. It is not as efficient as Syscall, but easier to use.
NewLazyDLL now supports non-ascii filenames.
LazyDLL and LazyProc now have Load and Find methods. These can be used
during runtime to discover if some dll functions are not present.
All dll functions now return errors that fit os.Error interface. They
also contain Windows error number.
Some of these changes are suggested by jp.
R=golang-dev, jp, rsc
CC=golang-dev
https://golang.org/cl/5272042
The work buffer management used by the garbage
collector during parallel collections leaks buffers.
This CL tests for and fixes the leak.
R=golang-dev, dvyukov, r
CC=golang-dev
https://golang.org/cl/5254059
Use FlagNoPointers and do not zeroize memory when allocate strings.
test/garbage/parser.out old new
run #1 32.923s 32.065s
run #2 33.047s 31.931s
run #3 32.702s 31.841s
run #4 32.718s 31.838s
run #5 32.702s 31.868s
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5259041
Implement a locking model based on the current linux model - a
tri-state mutex with active spinning, passive spinning and sleeping.
R=golang-dev, dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4974043
The malloc sample trigger was not being set in a
new m, so the first allocation in each new m - the
goroutine structure - was being sampled with
probability 1 instead of probability sizeof(G)/rate,
an oversampling of about 5000x for the default
rate of 1 MB. This bug made pprof graphs show
far more G allocations than there actually were.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5224041
Fixes#2337.
Unfortunate sequence of events is:
1. maxcpu=2, mcpu=1, grunning=1
2. starttheworld creates an extra M:
maxcpu=2, mcpu=2, grunning=1
4. the goroutine calls runtime.GOMAXPROCS(1)
maxcpu=1, mcpu=2, grunning=1
5. since it sees mcpu>maxcpu, it calls gosched()
6. schedule() deschedules the goroutine:
maxcpu=1, mcpu=1, grunning=0
7. schedule() call getnextandunlock() which
fails to pick up the goroutine again,
because canaddcpu() fails, because mcpu==maxcpu
8. then it sees that grunning==0,
reports deadlock and terminates
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5191044
When ncpu < 2, work.nproc is always 1 which results in infinite helper
threads being created if gomaxprocs > 1 and MaxGcproc > 1. Avoid this
by using the same limits as imposed helpgc().
R=golang-dev, rsc, dvyukov
CC=golang-dev
https://golang.org/cl/5176044
This change adds the osyield and usleep
functions and code to read the number of
processors from /dev/sysstat.
I also changed SysAlloc to return nil
when brk fails (it was returning -1).
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5177049
The map implementation was using the C idiom of using
a pointer just past the end of its table as a limit pointer.
Unfortunately, the garbage collector sees that pointer as
pointing at the block adjacent to the map table, pinning
in memory a block that would otherwise be freed.
Fix by making limit pointer point at last valid entry, not
just past it.
Reviewed by Mike Burrows.
R=golang-dev, bradfitz, lvd, r
CC=golang-dev
https://golang.org/cl/5158045
Running test/garbage/parser.out.
On a 4-core Lenovo X201s (Linux):
31.12u 0.60s 31.74r 1 cpu, no atomics
32.27u 0.58s 32.86r 1 cpu, atomic instructions
33.04u 0.83s 27.47r 2 cpu
On a 16-core Xeon (Linux):
33.08u 0.65s 33.80r 1 cpu, no atomics
34.87u 1.12s 29.60r 2 cpu
36.00u 1.87s 28.43r 3 cpu
36.46u 2.34s 27.10r 4 cpu
38.28u 3.85s 26.92r 5 cpu
37.72u 5.25s 26.73r 6 cpu
39.63u 7.11s 26.95r 7 cpu
39.67u 8.10s 26.68r 8 cpu
On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5):
39.43u 1.45s 41.27r 1 cpu, no atomics
43.98u 2.95s 38.69r 2 cpu
On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1):
48.81u 2.12s 51.76r 1 cpu, no atomics
57.15u 4.72s 51.54r 2 cpu
The handoff algorithm is really only good for two cores.
Beyond that we will need to so something more sophisticated,
like have each core hand off to the next one, around a circle.
Even so, the code is a good checkpoint; for now we'll limit the
number of gc procs to at most 2.
R=dvyukov
CC=golang-dev
https://golang.org/cl/4641082
The Dwarf info has the full typenames, the go *struct runtime.commonType
has the short name. A more permanent fix would link the two together
but this way the user gets useable stack traces for now.
R=rsc
CC=golang-dev
https://golang.org/cl/5097046
gotest src/pkg/exp/template/html was crashing because the exception handler overflowed the goroutine stack.
R=alex.brainman, golang-dev
CC=golang-dev
https://golang.org/cl/5031049
The Windows implementation of the net package churns through a couple of channels for every read/write operation. This translates into a lot of time spent in the kernel creating and deleting event objects.
R=rsc, dvyukov, alex.brainman, jp
CC=golang-dev
https://golang.org/cl/4997044
My string literal was being rewritten from
"runtime.SysReserve(%p, %D) = error %d"
to
"runtime.SysReserve ( %p , %D ) = error %d"
R=iant
CC=golang-dev
https://golang.org/cl/4972051
- Rename sys_sched_yield() to osyield() as this is now defined in asm.h.
- Only print kern.rtheads message if rfork_thread() failed with ENOTSUP.
- Remove unused variables.
R=rsc
CC=golang-dev
https://golang.org/cl/4973043
cdecl calbacks have been implemented in C/ASM code, just Go function is missing
R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/4969047
Make the stack traces more readable for new
Go programmers while preserving their utility for old hands.
- Change status number [4] to string.
- Elide frames in runtime package (internal details).
- Swap file:line and arguments.
- Drop 'created by' for main goroutine.
- Show goroutines in order of allocation:
implies main goroutine first if nothing else.
There is no option to get the extra frames back.
Uncomment 'return 1' at the bottom of symtab.c.
$ 6.out
throw: all goroutines are asleep - deadlock!
goroutine 1 [chan send]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:22 +0x8a
goroutine 2 [select (no cases)]:
main.sel()
/Users/rsc/g/go/src/pkg/runtime/x.go:11 +0x18
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:19 +0x23
goroutine 3 [chan receive]:
main.recv(0xf8400010a0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:20 +0x50
goroutine 4 [chan receive (nil chan)]:
main.recv(0x0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:21 +0x66
$
$ 6.out index
panic: runtime error: index out of range
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:25 +0xb9
$
$ 6.out nil
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x22ca]
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:28 +0x211
$
$ 6.out panic
panic: panic
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:30 +0x101
$
R=golang-dev, qyzhai, n13m3y3r, r
CC=golang-dev
https://golang.org/cl/4907048
Allocate Defer on stack during cgo calls, as suggested
by dvyukov. Also includes some comment corrections.
benchmark old,ns/op new,ns/op
BenchmarkCgoCall 669 330
(Intel Xeon CPU 1.80GHz * 4, Linux 386)
R=dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4910041
The corruption can occur when GOMAXPROCS
is changed from >1 to 1, since GOMAXPROCS=1
does not imply there is only 1 goroutine running,
other goroutines can still be not parked after
the change.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4873050
Every time we enter callback from Windows, it is
possible that go exception handler is not at the top
of per-thread exception handlers chain. So it needs
to be installed again. At this moment this is done
by replacing top SEH frame with SEH frame as at time
of syscall for the time of callback. This is incorrect,
because, if exception strike, we won't be able to call
any exception handlers installed inside syscall,
because they are not in the chain. This changes
procedure to add new SEH frame on top of existing
chain instead.
I also removed m sehframe field, because I don't
think it is needed. We use single global exception
handler everywhere.
R=golang-dev, r
CC=golang-dev, hectorchu
https://golang.org/cl/4832060
Add support for the go runtime on openbsd/amd64. This is based on
the existing freebsd runtime.
Threads are implemented using OpenBSD's rthreads, which are currently
disabled by default, however can be enabled via the kern.rthreads
sysctl.
For now, cgo is disabled.
R=rsc
CC=golang-dev
https://golang.org/cl/4815067
The change adds specialized type algorithms
for slices and types of size 8/16/32/64/128.
It significantly accelerates chan and map operations
for most builtin types as well as user structs.
benchmark old,ns/op new,ns/op
BenchmarkChanUncontended 226 94
(on Intel Xeon E5620, 2.4GHz, Linux 64 bit)
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4815087
The data race can lead to reads of partially
initialized concurrently mutated symbol data.
The change also adds a simple sanity test
for Caller() and FuncForPC().
R=rsc
CC=golang-dev
https://golang.org/cl/4817058
When rnd is called with a second argument of 1, it simply
returns the first argument anyway.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4820045
Replace cas with xadd in scheduler.
Suggested by Dmitriy in last code review.
Verified with Promela model.
When there's actual contention for the atomic word,
this avoids the looping that compare-and-swap requires.
benchmark old ns/op new ns/op delta
runtime_test.BenchmarkSyscall 32 26 -17.08%
runtime_test.BenchmarkSyscall-2 155 59 -61.81%
runtime_test.BenchmarkSyscall-3 112 52 -52.95%
runtime_test.BenchmarkSyscall-4 94 48 -48.57%
runtime_test.BenchmarkSyscallWork 871 872 +0.11%
runtime_test.BenchmarkSyscallWork-2 481 477 -0.83%
runtime_test.BenchmarkSyscallWork-3 338 335 -0.89%
runtime_test.BenchmarkSyscallWork-4 263 256 -2.66%
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/4800047
Drops mallocrep1.go back to a reasonable
amount of time. (154 -> 0.8 seconds on my Mac)
Fixes#2085.
R=golang-dev, dvyukov, r
CC=golang-dev
https://golang.org/cl/4811045
Remove complicated PRNG algorithm
(argument is limited by uint16 and can't be <= 1).
Do not require chansend/chanrecv selgen to be bumped with CAS.
R=rsc, ken
CC=golang-dev
https://golang.org/cl/4816041
pkg/runtime/Makefile:
. Adjusted so "goc2c.c" is built using the Plan 9 libraries.
pkg/runtime/goc2c.c:
. Added/subtracted #include headers to correspond to Plan 9
toolkit.
. Changed fprintf(stderr,...)/exit() combinations to
sysfatal() calls, adjusted the "%u" format to "%ud".
. Added exits(0) at the end of main().
. Made main() a void-returning function and removed the
"return 0" at the end of it.
Tested on UBUNTU and Plan 9 only.
R=r, rsc
CC=golang-dev
https://golang.org/cl/4626093
Used to use mcpu+msyscall but that's
problematic for packing into a single
atomic word. The running goroutine count
(where running == Go code or syscall)
can be maintained separately, always
manipulated under lock.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/4767041
The data race is on newly published Itab nodes, which are
both unsafely published and unsafely acquired. It can
break on IA-32/Intel64 due to compiler optimizations
(most likely not an issue as of now) and on ARM due to
hardware memory access reorderings.
R=rsc
CC=golang-dev
https://golang.org/cl/4673055
runtime.goidgen can be quite frequently modified and
shares cache line with the following variables,
it leads to false sharing.
50c6b0 b nfname
50c6b4 b nfunc
50c6b8 b nfunc$17
50c6bc b nhist$17
50c6c0 B runtime.checking
50c6c4 B runtime.gcwaiting
50c6c8 B runtime.goidgen
50c6cc B runtime.gomaxprocs
50c6d0 B runtime.panicking
50c6d4 B strconv.IntSize
50c6d8 B src/pkg/runtime/_xtest_.ss
50c6e0 B src/pkg/runtime/_xtest_.stop
50c6e8 b addrfree
50c6f0 b addrmem
50c6f8 b argv
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4673054
Change the signature of Split to have no count,
assuming a full split, and rename the existing
Split with a count to SplitN.
Do the same to package bytes.
Add a gofix module.
R=adg, dsymonds, alex.brainman, rsc
CC=golang-dev
https://golang.org/cl/4661051
grsec needs the FIXED flag to be provided to mmap, which
works now. That said, when the allocation fails to be made
in the specific address, we're still given back a writable
page. This change will unmap that page to avoid using
twice the amount of memory needed.
It'd also be pretty easy to avoid the extra system calls
once we detected that the flag is needed, but I'm not sure
if that edge case is worth the effort.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4634086
All but two packages depend on net:
debug/proc
os/signal
With this change, we can produce
a working build with GOOS=plan9.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4639053
Correct a few error messages (libcgo -> runtime/cgo)
and delete old nacl_386.c file too.
Fixes#1657.
R=iant
CC=golang-dev
https://golang.org/cl/4603057
5a: add SQRTF and SQRTD
5l: add ASQRTF and ASQRTD
Use ARMv7 VFP VSQRT instruction to speed up math.Sqrt
R=rsc, dave, m
CC=golang-dev
https://golang.org/cl/4551082
This change was adapted from gccgo's libgo/runtime/mem.c at
Ian Taylor's suggestion. It fixes all.bash failing with
"address space conflict: map() =" on amd64 Linux with kernel
version 2.6.32.8-grsec-2.1.14-modsign-xeon-64.
With this change, SysMap will use MAP_FIXED to allocate its desired
address space, after first calling mincore to check that there is
nothing else mapped there.
R=iant, dave, n13m3y3r, rsc
CC=golang-dev
https://golang.org/cl/4438091
breaks Mac build
««« original CL description
runtime: use HOST_CC to compile mkversion
HOST_CC is set in Make.inc, so use that rather
than hardcoding quietgcc
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/4515163
»»»
R=iant
CC=golang-dev
https://golang.org/cl/4515168
Works around bug in kernel implementation on old ARM5 kernels.
Bug was fixed on 26 Nov 2007 (between 2.6.23 and 2.6.24) but
old kernels persist.
Fixes#1750.
R=dfc, golang-dev
CC=golang-dev
https://golang.org/cl/4436072
The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).
That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls. Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.
The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp. In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number. Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory. On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number. Scanblock would not scan anything, possibly
causing in-use blocks to be freed.
In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.
Fixes#1620.
Fixes#1746.
R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory
runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80
R=iant, r
CC=golang-dev
https://golang.org/cl/4444073
In a GOROOT path a backslash is a path separator
not an escape character. For example, `C:\go`.
Fixes gotest error:
version.go:3: unknown escape sequence: g
R=rsc
CC=golang-dev
https://golang.org/cl/4437076
Used to fault trying to access l->list->next
when l->list == nil after MCentral_AllocList.
Now prints
runtime: out of memory: no room in arena for 65536-byte allocation (536870912 in use)
throw: out of memory
followed by stack trace.
Fixes#1650.
R=r, dfc
CC=golang-dev
https://golang.org/cl/4446062
Avoid getting out of synch when a function, such as main.init,
has no associated line number information. Without this the
function before main.init can skip the PC all the way to the
next function, which will cause the next function's line table
to be associated with main.init, and leave subsequent
functions with the wrong line numbers.
R=rsc
CC=golang-dev
https://golang.org/cl/4426055
go/types: update for export data format change
reflect: require package qualifiers to match during interface check
runtime: require package qualifiers to match during interface check
test: fixed bug324, adapt to be silent
Fixes#1550.
Issue 1536 remains open.
R=gri, ken2, r
CC=golang-dev
https://golang.org/cl/4442071
* Reduces malloc counts during gob encoder/decoder test from 6/6 to 3/5.
The current reflect uses Set to mean two subtly different things.
(1) If you have a reflect.Value v, it might just represent
itself (as in v = reflect.NewValue(42)), in which case calling
v.Set only changed v, not any other data in the program.
(2) If you have a reflect Value v derived from a pointer
or a slice (as in x := []int{42}; v = reflect.NewValue(x).Index(0)),
v represents the value held there. Changing x[0] affects the
value returned by v.Int(), and calling v.Set affects x[0].
This was not really by design; it just happened that way.
The motivation for the new reflect implementation was
to remove mallocs. The use case (1) has an implicit malloc
inside it. If you can do:
v := reflect.NewValue(0)
v.Set(42)
i := v.Int() // i = 42
then that implies that v is referring to some underlying
chunk of memory in order to remember the 42; that is,
NewValue must have allocated some memory.
Almost all the time you are using reflect the goal is to
inspect or to change other data, not to manipulate data
stored solely inside a reflect.Value.
This CL removes use case (1), so that an assignable
reflect.Value must always refer to some other piece of data
in the program. Put another way, removing this case would
make
v := reflect.NewValue(0)
v.Set(42)
as illegal as
0 = 42.
It would also make this illegal:
x := 0
v := reflect.NewValue(x)
v.Set(42)
for the same reason. (Note that right now, v.Set(42) "succeeds"
but does not change the value of x.)
If you really wanted to make v refer to x, you'd start with &x
and dereference it:
x := 0
v := reflect.NewValue(&x).Elem() // v = *&x
v.Set(42)
It's pretty rare, except in tests, to want to use NewValue and then
call Set to change the Value itself instead of some other piece of
data in the program. I haven't seen it happen once yet while
making the tree build with this change.
For the same reasons, reflect.Zero (formerly reflect.MakeZero)
would also return an unassignable, unaddressable value.
This invalidates the (awkward) idiom:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.PointTo(v)
which, when the API changed, turned into:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.Set(v.Addr())
In both, it is far from clear what the code is trying to do. Now that
it is possible, this CL adds reflect.New(Type) Value that does the
obvious thing (same as Go's new), so this code would be replaced by:
pv := ... some Ptr Value we have ...
pv.Set(reflect.New(pv.Type().Elem()))
The changes just described can be confusing to think about,
but I believe it is because the old API was confusing - it was
conflating two different kinds of Values - and that the new API
by itself is pretty simple: you can only Set (or call Addr on)
a Value if it actually addresses some real piece of data; that is,
only if it is the result of dereferencing a Ptr or indexing a Slice.
If you really want the old behavior, you'd get it by translating:
v := reflect.NewValue(x)
into
v := reflect.New(reflect.Typeof(x)).Elem()
v.Set(reflect.NewValue(x))
Gofix will not be able to help with this, because whether
and how to change the code depends on whether the original
code meant use (1) or use (2), so the developer has to read
and think about the code.
You can see the effect on packages in the tree in
https://golang.org/cl/4423043/.
R=r
CC=golang-dev
https://golang.org/cl/4435042
. Missing declaration of runtime.brk_();
. Argument v in runtime.SysReserve() is not used;
(I'd prefer a Plan 9-type solution...)
R=golang-dev, r, r2
CC=golang-dev
https://golang.org/cl/4368076
The list elements are already being allocated out of a
single memory buffer. We can drop the Link* pointer
following and the memory it requires, replacing it with
index operations.
The change also keeps a channel from containing a pointer
back into its own allocation block, which would create a
cycle. Blocks involved in cycles are not guaranteed to be
finalized properly, and channels depend on finalizers to
free OS-level locks on some systems. The self-reference
was keeping channels from being garbage collected.
runtime-gdb.py will need to be updated in order to dump
the content of buffered channels with the new data structure.
Fixes#1676.
R=ken2, r
CC=golang-dev
https://golang.org/cl/4411045
in gdb, 'info goroutines' and 'goroutine <n> <cmd> were crashing
because the 'g' and 'm' structures had changed a bit.
R=rsc
CC=golang-dev
https://golang.org/cl/4289077
On darwin amd64 it was impossible to create more that ~132 threads. While
investigating I noticed that go consumes almost 1TB of virtual memory per
OS thread and the reason for such a small limit of OS thread was because
process was running out of virtual memory. While looking at bsdthread_create
I noticed that on amd64 it wasn't using PTHREAD_START_CUSTOM.
If you look at http://fxr.watson.org/fxr/source/bsd/kern/pthread_synch.c?v=xnu-1228
you will see that in that case darwin will use stack pointer as stack size,
allocating huge amounts of memory for stack. This change fixes the issue
and allows for creation of up to 2560 OS threads (which appears to be some
Mac OS X limit) with relatively small virtual memory consumption.
R=rsc
CC=golang-dev
https://golang.org/cl/4289075
Fixes#1641.
Actually it side steps the real issue, which is that the
setitimer(2) implementation on OS X is not useful for
profiling of multi-threaded programs. I filed the below
using the Apple Bug Reporter.
/*
Filed as Apple Bug Report #9177434.
This program creates a new pthread that loops, wasting cpu time.
In the main pthread, it sleeps on a condition that will never come true.
Before doing so it sets up an interval timer using ITIMER_PROF.
The handler prints a message saying which thread it is running on.
POSIX does not specify which thread should receive the signal, but
in order to be useful in a user-mode self-profiler like pprof or gprof
http://code.google.com/p/google-perftoolshttp://www.delorie.com/gnu/docs/binutils/gprof_25.html
it is important that the thread that receives the signal is the one
whose execution caused the timer to expire.
Linux and FreeBSD handle this by sending the signal to the process's
queue but delivering it to the current thread if possible:
http://lxr.linux.no/linux+v2.6.38/kernel/signal.c#L802
807 /*
808 * Now find a thread we can wake up to take the signal off the queue.
809 *
810 * If the main thread wants the signal, it gets first crack.
811 * Probably the least surprising to the average bear.
812 * /
http://fxr.watson.org/fxr/source/kern/kern_sig.c?v=FREEBSD8;im=bigexcerpts#L1907
1914 /*
1915 * Check if current thread can handle the signal without
1916 * switching context to another thread.
1917 * /
On those operating systems, this program prints:
$ ./a.out
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
$
The OS X kernel does not have any such preference. Its get_signalthread
does not prefer current_thread(), in contrast to the other two systems,
so the signal gets delivered to the first thread in the list that is able to
handle it, which ends up being the main thread in this experiment.
http://fxr.watson.org/fxr/source/bsd/kern/kern_sig.c?v=xnu-1456.1.26;im=excerpts#L1666
$ ./a.out
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
$
The fix is to make get_signalthread use the same heuristic as
Linux and FreeBSD, namely to use current_thread() if possible
before scanning the process thread list.
*/
#include <sys/time.h>
#include <sys/signal.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
static void handler(int);
static void* looper(void*);
static pthread_t pmain, ploop;
int
main(void)
{
struct itimerval it;
struct sigaction sa;
pthread_cond_t cond;
pthread_mutex_t mu;
memset(&sa, 0, sizeof sa);
sa.sa_handler = handler;
sa.sa_flags = SA_RESTART;
memset(&sa.sa_mask, 0xff, sizeof sa.sa_mask);
sigaction(SIGPROF, &sa, 0);
pmain = pthread_self();
pthread_create(&ploop, 0, looper, 0);
memset(&it, 0, sizeof it);
it.it_interval.tv_usec = 10000;
it.it_value = it.it_interval;
setitimer(ITIMER_PROF, &it, 0);
pthread_mutex_init(&mu, 0);
pthread_mutex_lock(&mu);
pthread_cond_init(&cond, 0);
for(;;)
pthread_cond_wait(&cond, &mu);
return 0;
}
static void
handler(int sig)
{
static int nsig;
pthread_t p;
p = pthread_self();
if(p == pmain)
printf("signal on sleeping main thread\n");
else if(p == ploop)
printf("signal on cpu-chewing looper thread\n");
else
printf("signal on %p\n", (void*)p);
if(++nsig >= 10)
exit(0);
}
static void*
looper(void *v)
{
for(;;);
}
R=r
CC=golang-dev
https://golang.org/cl/4273113
Also fix comment.
The only caller of chanrecv initializes the value to false, so
this patch makes no difference at present. But it seems like
the right thing to do.
R=rsc
CC=golang-dev
https://golang.org/cl/4312053
* Change use of m->g0 stack (aka scheduler stack).
* Provide runtime.mcall(f) to invoke f() on m->g0 stack.
* Replace scheduler loop entry with runtime.mcall(schedule).
Runtime.mcall eliminates the need for fake scheduler states that
exist just to run a bit of code on the m->g0 stack
(Grecovery, Gstackalloc).
The elimination of the scheduler as a loop that stops and
starts using gosave and gogo fixes a bad interaction with the
way cgo uses the m->g0 stack. Cgo runs external (gcc-compiled)
C functions on that stack, and then when calling back into Go,
it sets m->g0->sched.sp below the added call frames, so that
other uses of m->g0's stack will not interfere with those frames.
Unfortunately, gogo (longjmp) back to the scheduler loop at
this point would end up running scheduler with the lower
sp, which no longer points at a valid stack frame for
a call to scheduler. If scheduler then wrote any function call
arguments or local variables to where it expected the stack
frame to be, it would overwrite other data on the stack.
I realized this possibility while debugging a problem with
calling complex Go code in a Go -> C -> Go cgo callback.
This wasn't the bug I was looking for, it turns out, but I believe
it is a real bug nonetheless. Switching to runtime.mcall, which
only adds new frames to the stack and never jumps into
functions running in existing ones, fixes this bug.
* Move cgo-related code out of proc.c into cgocall.c.
* Add very large comment describing cgo call sequences.
* Simpilify, regularize cgo function implementations and names.
* Add test suite as misc/cgo/test.
Now the Go -> C path calls cgocall, which calls asmcgocall,
and the C -> Go path calls cgocallback, which calls cgocallbackg.
The shuffling, which affects mainly the callback case, moves
most of the callback implementation to cgocallback running
on the m->curg stack (not the m->g0 scheduler stack) and
only while accounted for with $GOMAXPROCS (between calls
to exitsyscall and entersyscall).
The previous callback code did not block in startcgocallback's
approximation to exitsyscall, so if, say, the garbage collector
were running, it would still barge in and start doing things
like call malloc. Similarly endcgocallback's approximation of
entersyscall did not call matchmg to kick off new OS threads
when necessary, which caused the bug in issue 1560.
Fixes#1560.
R=iant
CC=golang-dev
https://golang.org/cl/4253054
This functionality might be used in environments
where programs are limited to a single thread,
to simulate a select-driven network server. It is
not exposed via the standard runtime API.
R=r, r2
CC=golang-dev
https://golang.org/cl/4254041
Using the kernel-supplied compare-and-swap code
on linux/arm means that runtime doesn't have to care
whether this is GOARM=5 or GOARM=6 anymore.
Fixes#1494.
R=r, r2
CC=golang-dev
https://golang.org/cl/4245043
The pointer will eventually let us find *T given T.
This CL just makes room for it, always storing a zero.
R=r, r2
CC=golang-dev
https://golang.org/cl/4221046
In CL 4188061 I changed malg to allocate the requested
number of bytes n, not n+StackGuard, so that the
allocations would use rounder numbers.
The allocation of the signal stack asks for 32k and
then used g->stackguard as the base, but g->stackguard
is StackGuard bytes above the base. Previously, asking
for 32k meant getting 32k+StackGuard bytes, so using
g->stackguard as the base was safe. Now, the actual base
must be computed, so that the signal handler does not
run StackGuard bytes past the top of the stack.
Was causing flakiness mainly in programs that use the
network, because they sometimes write to closed network
connections, causing SIGPIPEs. Was also causing problems
in the doc/progs test.
Also fix Makefile so that changes to stack.h trigger rebuild.
R=bradfitzgo, r, r2
CC=golang-dev
https://golang.org/cl/4230044
Avoids deadlocks like the one below, in which a stack split happened
in order to call lock(&stacks), but then the stack unsplit cannot run
because stacks is now locked.
The only code calling stackalloc that wasn't on a scheduler
stack already was malg, which creates a new goroutine.
runtime.futex+0x23 /home/rsc/g/go/src/pkg/runtime/linux/amd64/sys.s:139
runtime.futex()
futexsleep+0x50 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:51
futexsleep(0x5b0188, 0x300000003, 0x100020000, 0x4159e2)
futexlock+0x85 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:119
futexlock(0x5b0188, 0x5b0188)
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
runtime.lock(0x5b0188, 0x7f0d27b4a000)
runtime.stackfree+0x4d /home/rsc/g/go/src/pkg/runtime/malloc.goc:336
runtime.stackfree(0x7f0d27b4a000, 0x1000, 0x8, 0x7fff37e1e218)
runtime.oldstack+0xa6 /home/rsc/g/go/src/pkg/runtime/proc.c:705
runtime.oldstack()
runtime.lessstack+0x22 /home/rsc/g/go/src/pkg/runtime/amd64/asm.s:224
runtime.lessstack()
----- lessstack called from goroutine 2 -----
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
runtime.lock(0x5b0188, 0x40a5e2)
runtime.stackalloc+0x55 /home/rsc/g/go/src/pkg/runtime/malloc.c:316
runtime.stackalloc(0x1000, 0x4055b0)
runtime.malg+0x3d /home/rsc/g/go/src/pkg/runtime/proc.c:803
runtime.malg(0x1000, 0x40add9)
runtime.newproc1+0x12b /home/rsc/g/go/src/pkg/runtime/proc.c:854
runtime.newproc1(0xf840027440, 0x7f0d27b49230, 0x0, 0x49f238, 0x40, ...)
runtime.newproc+0x2f /home/rsc/g/go/src/pkg/runtime/proc.c:831
runtime.newproc(0x0, 0xf840027440, 0xf800000010, 0x44b059)
...
R=r, r2
CC=golang-dev
https://golang.org/cl/4216045
A terminal panic (one that prints a stack trace and exits)
has been calling runtime.breakpoint before calling exit,
so that if running under a debugger, the debugger can
take control. When not running under a debugger, though,
this causes an additional SIGTRAP on Unix and pop-up
dialogs on Windows.
Support for debugging Go programs has gotten good
enough that we can rely on the debugger to set its own
breakpoint on runtime.exit if it wants to look around.
R=r, r2
CC=golang-dev
https://golang.org/cl/4222043
The existing code assumed that signals only arrived
while executing on the goroutine stack (g == m->curg),
not while executing on the scheduler stack (g == m->g0).
Most of the signal handling trampolines correctly saved
and restored g already, but the sighandler C code did not
have access to it.
Some rewriting of assembly to make the various
implementations as similar as possible.
Will need to change Windows too but I don't
understand how sigtramp gets called there.
R=r
CC=golang-dev
https://golang.org/cl/4203042
With this change, a panic trace due to a signal arriving while
running on the scheduler stack during a lessstack
(a stack unsplit) will trace through the lessstack to show
the state of the goroutine that was unsplitting its stack.
R=r
CC=golang-dev
https://golang.org/cl/4206042
Fix problems found.
On amd64, various library routines had bigger
stack frames than expected, because large function
calls had been added.
runtime.assertI2T: nosplit stack overflow
120 assumed on entry to runtime.assertI2T
8 after runtime.assertI2T uses 112
0 on entry to runtime.newTypeAssertionError
-8 on entry to runtime.morestack01
runtime.assertE2E: nosplit stack overflow
120 assumed on entry to runtime.assertE2E
16 after runtime.assertE2E uses 104
8 on entry to runtime.panic
0 on entry to runtime.morestack16
-8 after runtime.morestack16 uses 8
runtime.assertE2T: nosplit stack overflow
120 assumed on entry to runtime.assertE2T
16 after runtime.assertE2T uses 104
8 on entry to runtime.panic
0 on entry to runtime.morestack16
-8 after runtime.morestack16 uses 8
runtime.newselect: nosplit stack overflow
120 assumed on entry to runtime.newselect
56 after runtime.newselect uses 64
48 on entry to runtime.printf
8 after runtime.printf uses 40
0 on entry to vprintf
-8 on entry to runtime.morestack16
runtime.selectdefault: nosplit stack overflow
120 assumed on entry to runtime.selectdefault
56 after runtime.selectdefault uses 64
48 on entry to runtime.printf
8 after runtime.printf uses 40
0 on entry to vprintf
-8 on entry to runtime.morestack16
runtime.selectgo: nosplit stack overflow
120 assumed on entry to runtime.selectgo
0 after runtime.selectgo uses 120
-8 on entry to runtime.gosched
On arm, 5c was tagging functions NOSPLIT that should
not have been, like the recursive function printpanics:
printpanics: nosplit stack overflow
124 assumed on entry to printpanics
112 after printpanics uses 12
108 on entry to printpanics
96 after printpanics uses 12
92 on entry to printpanics
80 after printpanics uses 12
76 on entry to printpanics
64 after printpanics uses 12
60 on entry to printpanics
48 after printpanics uses 12
44 on entry to printpanics
32 after printpanics uses 12
28 on entry to printpanics
16 after printpanics uses 12
12 on entry to printpanics
0 after printpanics uses 12
-4 on entry to printpanics
R=r, r2
CC=golang-dev
https://golang.org/cl/4188061
