aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime
AgeCommit message (Collapse)Author
2013-11-01[release-branch.go1.2] cmd/5l, runtime: fix divide for profiling tracebacks ↵Andrew Gerrand
on ARM ««« CL 19910044 / 9eb64f5ef3a6 cmd/5l, runtime: fix divide for profiling tracebacks on ARM Two bugs: 1. The first iteration of the traceback always uses LR when provided, which it is (only) during a profiling signal, but in fact LR is correct only if the stack frame has not been allocated yet. Otherwise an intervening call may have changed LR, and the saved copy in the stack frame should be used. Fix in traceback_arm.c. 2. The division runtime call adds 8 bytes to the stack. In order to keep the traceback routines happy, it must copy the saved LR into the new 0(SP). Change SUB $8, SP into MOVW 0(SP), R11 // r11 is temporary, for use by linker MOVW.W R11, -8(SP) to update SP and 0(SP) atomically, so that the traceback always sees a saved LR at 0(SP). Fixes #6681. R=golang-dev, r CC=golang-dev https://golang.org/cl/19910044 »»» R=golang-dev CC=golang-dev https://golang.org/cl/20170048
2013-11-01[release-branch.go1.2] runtime: relax preemption assertion during stack splitAndrew Gerrand
««« CL 18740044 / 1a8903f0a577 runtime: relax preemption assertion during stack split The case can happen when starttheworld is calling acquirep to get things moving again and acquirep gets preempted. The stack trace is in golang.org/issue/6644. It is difficult to build a short test case for this, but the person who reported issue 6644 confirms that this solves the problem. Fixes #6644. R=golang-dev, r CC=golang-dev https://golang.org/cl/18740044 »»» R=golang-dev CC=golang-dev https://golang.org/cl/20460044
2013-11-01[release-branch.go1.2] runtime: remove nomemprofAndrew Gerrand
««« CL 14695044 / 35d5bae6aac8 runtime: remove nomemprof Nomemprof seems to be unneeded now, there is no recursion. If the recursion will be re-introduced, it will break loudly by deadlocking. Fixes #6566. R=golang-dev, minux.ma, rsc CC=golang-dev https://golang.org/cl/14695044 »»» R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/20540043
2013-10-17runtime: correct test for when to poll networkIan Lance Taylor
Fixes #6610. R=golang-dev, khr CC=golang-dev https://golang.org/cl/14793043
2013-10-17runtime: correct parameter name in MCentral_AllocList commentIan Lance Taylor
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/14792043
2013-10-15undo CL 14231047 / 2f4c2dde2756Alex Brainman
undone because the change slows down profile collection significantly and unpredictable at times (see comments at https://golang.org/cl/14231047 for details) ««« original CL description runtime: collect profiles even while on g0 stack Fixes #6417 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/14231047 »»» R=golang-dev, rsc CC=golang-dev https://golang.org/cl/14535046
2013-10-15runtime/pprof: disable flaky TestGoroutineSwitch on windowsAlex Brainman
Update #6417 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/14604043
2013-10-09runtime: markfreed's error reports should be prefixed with "markfreed", not ↵Keith Randall
"markallocated". R=golang-dev, iant CC=golang-dev https://golang.org/cl/14441055
2013-10-09runtime/cgo: mark callback functions as NOSPLITIan Lance Taylor
R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/14448044
2013-10-08cmd/go, runtime: express armv5t architecture constraint differentlyCarl Shapiro
Instead of adding an -march=armv5t flag to the gcc command line, the same effect is obtained with an ".arch armv5t" pseudo op in the assembly file that uses armv5t instructions. R=golang-dev, iant, dave CC=golang-dev https://golang.org/cl/14511044
2013-10-04runtime: fix bug in maps at the intersection of iterators, growing, and NaN keysKeith Randall
If an iterator is started while a map is in the middle of a grow, and the map has NaN keys, then those keys might get returned by the iterator more than once. This fix makes the evacuation decision deterministic and repeatable for NaN keys so each one gets returned only once. R=golang-dev, r, khr, iant CC=golang-dev https://golang.org/cl/14367043
2013-10-04runtime: remove 3 unused declarations.Keith Randall
R=golang-dev, cshapiro, iant CC=golang-dev https://golang.org/cl/14405043
2013-10-04runtime: collect profiles even while on g0 stackAlex Brainman
Fixes #6417 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/14231047
2013-10-03runtime: change default stack segment size to 8 kBRuss Cox
Changing from 4 kB to 8 kB brings significant improvement on a variety of the Go 1 benchmarks, on both amd64 and 386 systems. Significant runtime reductions: amd64 386 GoParse -14% -1% GobDecode -12% -20% GobEncode -64% -1% JSONDecode -9% -4% JSONEncode -15% -5% Template -17% -14% In the longer term, khr's new stacks will avoid needing to make this decision at all, but for Go 1.2 this is a reasonable stopgap that makes performance significantly better. Demand paging should mean that if the second 4 kB is not used, it will not be brought into memory, so the change should not adversely affect resident set size. The same argument could justify bumping as high as 64 kB on 64-bit machines, but there are diminishing returns after 8 kB, and using 8 kB limits the possible unintended memory overheads we are not aware of. Benchmark graphs at http://swtch.com/~rsc/gostackamd64.html http://swtch.com/~rsc/gostack386.html Full data at http://swtch.com/~rsc/gostack.zip R=golang-dev, khr, dave, bradfitz, dvyukov CC=golang-dev https://golang.org/cl/14317043
2013-10-02runtime: remove syscall.NewCallbackCDecl on WindowsRuss Cox
It is not possible to use (there is no declaration in package syscall), and no one seems to care. Alex Brainman may bring this back properly for Go 1.3. Fixes #6338. R=golang-dev, r, alex.brainman CC=golang-dev https://golang.org/cl/14287043
2013-10-02runtime: fix finalizer test on amd64Russ Cox
Not scanning the stack by frames means we are reintroducing a few false positives into the collection. Run the finalizer registration in its own goroutine so that stack is guaranteed to be out of consideration in a later collection. This is working around a regression from yesterday's tip, but it's not a regression from Go 1.1. R=golang-dev TBR=golang-dev CC=golang-dev https://golang.org/cl/14290043
2013-10-02runtime: do not scan stack by frames during garbage collectionRuss Cox
Walking the stack by frames is ~3x more expensive than not, and since it didn't end up being precise, there is not enough benefit to outweigh the cost. This is the conservative choice: this CL makes the stack scanning behavior the same as it was in Go 1.1. Add benchmarks to package runtime so that we have them when we re-enable this feature during the Go 1.3 development. benchmark old ns/op new ns/op delta BenchmarkGoroutineSelect 3194909 1272092 -60.18% BenchmarkGoroutineBlocking 3120282 866366 -72.23% BenchmarkGoroutineForRange 3256179 939902 -71.13% BenchmarkGoroutineIdle 2005571 482982 -75.92% The Go 1 benchmarks, just to add more data. As far as I can tell the changes are mainly noise. benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 4409403046 4414734932 +0.12% BenchmarkFannkuch11 3407708965 3378306120 -0.86% BenchmarkFmtFprintfEmpty 100 99 -0.60% BenchmarkFmtFprintfString 242 239 -1.24% BenchmarkFmtFprintfInt 204 206 +0.98% BenchmarkFmtFprintfIntInt 320 316 -1.25% BenchmarkFmtFprintfPrefixedInt 295 299 +1.36% BenchmarkFmtFprintfFloat 442 435 -1.58% BenchmarkFmtManyArgs 1246 1216 -2.41% BenchmarkGobDecode 10186951 10051210 -1.33% BenchmarkGobEncode 16504381 16445650 -0.36% BenchmarkGzip 447030885 447056865 +0.01% BenchmarkGunzip 111056154 111696305 +0.58% BenchmarkHTTPClientServer 89973 93040 +3.41% BenchmarkJSONEncode 28174182 27933893 -0.85% BenchmarkJSONDecode 106353777 110443817 +3.85% BenchmarkMandelbrot200 4822289 4806083 -0.34% BenchmarkGoParse 6102436 6142734 +0.66% BenchmarkRegexpMatchEasy0_32 133 132 -0.75% BenchmarkRegexpMatchEasy0_1K 372 373 +0.27% BenchmarkRegexpMatchEasy1_32 113 111 -1.77% BenchmarkRegexpMatchEasy1_1K 964 940 -2.49% BenchmarkRegexpMatchMedium_32 202 205 +1.49% BenchmarkRegexpMatchMedium_1K 68862 68858 -0.01% BenchmarkRegexpMatchHard_32 3480 3407 -2.10% BenchmarkRegexpMatchHard_1K 108255 112614 +4.03% BenchmarkRevcomp 751393035 743929976 -0.99% BenchmarkTemplate 139637041 135402220 -3.03% BenchmarkTimeParse 479 475 -0.84% BenchmarkTimeFormat 460 466 +1.30% benchmark old MB/s new MB/s speedup BenchmarkGobDecode 75.34 76.36 1.01x BenchmarkGobEncode 46.50 46.67 1.00x BenchmarkGzip 43.41 43.41 1.00x BenchmarkGunzip 174.73 173.73 0.99x BenchmarkJSONEncode 68.87 69.47 1.01x BenchmarkJSONDecode 18.25 17.57 0.96x BenchmarkGoParse 9.49 9.43 0.99x BenchmarkRegexpMatchEasy0_32 239.58 241.74 1.01x BenchmarkRegexpMatchEasy0_1K 2749.74 2738.00 1.00x BenchmarkRegexpMatchEasy1_32 282.49 286.32 1.01x BenchmarkRegexpMatchEasy1_1K 1062.00 1088.96 1.03x BenchmarkRegexpMatchMedium_32 4.93 4.86 0.99x BenchmarkRegexpMatchMedium_1K 14.87 14.87 1.00x BenchmarkRegexpMatchHard_32 9.19 9.39 1.02x BenchmarkRegexpMatchHard_1K 9.46 9.09 0.96x BenchmarkRevcomp 338.26 341.65 1.01x BenchmarkTemplate 13.90 14.33 1.03x Fixes #6482. R=golang-dev, dave, r CC=golang-dev https://golang.org/cl/14257043
2013-09-27all: fix some mistakes found by go tool vet .Rob Pike
R=golang-dev, iant, adg CC=golang-dev https://golang.org/cl/14000043
2013-09-26runtime, syscall: update freebsd/arm calling convention to match EABIDave Cheney
Fixes #6451. There is still some breakages unrelated to the syscall change. [root@beaglebone ~/go/src]# /root/go/pkg/tool/freebsd_arm/go_bootstrap version go version devel freebsd/arm a std@beaglebone ~/go/src]# /root/go/pkg/tool/freebsd_arm/go_bootstrap install - fatal error: mark - finalizer inconsistency runtime stack: runtime.throw(0x3e80ac) /root/go/src/pkg/runtime/panic.c:464 +0x5c addfinroots(0x2) /root/go/src/pkg/runtime/mgc0.c:1501 +0x74 runtime.walkfintab(0x6c200) /root/go/src/pkg/runtime/mfinal.c:216 +0xa0 addroots() /root/go/src/pkg/runtime/mgc0.c:1561 +0x188 gc(0x50632f78) /root/go/src/pkg/runtime/mgc0.c:2098 +0x19c mgc(0x306170a0) /root/go/src/pkg/runtime/mgc0.c:2049 +0x30 runtime.mcall(0x3e97b0) /root/go/src/pkg/runtime/asm_arm.s:165 +0x3c goroutine 1 [garbage collection]: runtime.gc(0x0) /root/go/src/pkg/runtime/mgc0.c:2020 +0x1a0 fp=0x50632f80 runtime.mallocgc(0x680, 0x1b1971, 0x1) /root/go/src/pkg/runtime/malloc.goc:143 +0x210 fp=0x50632fbc ----- stack segment boundary ----- cnew(0x1b1970, 0x640, 0x1) /root/go/src/pkg/runtime/malloc.goc:718 +0xc4 fp=0x50626110 runtime.cnewarray(0x1b1970, 0x640) /root/go/src/pkg/runtime/malloc.goc:731 +0x3c fp=0x50626120 makeslice1(0x1ac6d0, 0x500, 0x640, 0x50626190) /root/go/src/pkg/runtime/slice.c:57 +0x50 fp=0x5062612c growslice1(0x1ac6d0, 0x30714a00, 0x500, 0x500, 0x501, ...) /root/go/src/pkg/runtime/slice.c:113 +0x8c fp=0x50626144 runtime.growslice(0x1ac6d0, 0x30714a00, 0x500, 0x500, 0x1, ...) /root/go/src/pkg/runtime/slice.c:80 +0x19c fp=0x50626174 go/build.(*importReader).readByte(0x3070d1b0, 0xb384e) /root/go/src/pkg/go/build/read.go:43 +0xbc fp=0x506261b4 go/build.(*importReader).peekByte(0x3070d1b0, 0x3070d101, 0x3070d180) /root/go/src/pkg/go/build/read.go:89 +0x210 fp=0x506261d0 go/build.readComments(0x203e2560, 0x306f79a8, 0x306f79a8, 0x203e2560, 0x306f79a8, ...) /root/go/src/pkg/go/build/read.go:194 +0x84 fp=0x506261f4 go/build.(*Context).matchFile(0x3e9730, 0x306209c0, 0x13, 0x306c42b4, 0x5, ...) /root/go/src/pkg/go/build/build.go:812 +0x74c fp=0x5062629c go/build.(*Context).Import(0x3e9730, 0x1f95c8, 0x1, 0x30620960, 0x13, ...) /root/go/src/pkg/go/build/build.go:580 +0xd64 fp=0x506268dc go/build.(*Context).ImportDir(0x3e9730, 0x30620960, 0x13, 0x0, 0x24d901, ...) /root/go/src/pkg/go/build/build.go:397 +0x5c fp=0x50626904 main.func·021(0x30620960, 0x13, 0x203e2200, 0x30680330, 0x0, ...) /root/go/src/cmd/go/main.go:521 +0x2cc fp=0x5062696c path/filepath.walk(0x30620960, 0x13, 0x203e2200, 0x30680330, 0x50626ae8, ...) /root/go/src/pkg/path/filepath/path.go:341 +0x5c fp=0x506269d8 path/filepath.walk(0x3067e720, 0x11, 0x203e2200, 0x30680210, 0x50626ae8, ...) /root/go/src/pkg/path/filepath/path.go:359 +0x308 fp=0x50626a44 path/filepath.Walk(0x3067e720, 0x11, 0x50626ae8, 0x1f9728, 0x1) /root/go/src/pkg/path/filepath/path.go:380 +0xb4 fp=0x50626a68 main.matchPackages(0xbfffedea, 0x3, 0x1b1190, 0x3067e600, 0x10) /root/go/src/cmd/go/main.go:530 +0x2c0 fp=0x50626b1c main.allPackages(0xbfffedea, 0x3, 0x1fadc8, 0x3, 0x1) /root/go/src/cmd/go/main.go:474 +0x34 fp=0x50626b70 main.importPathsNoDotExpansion(0x30620018, 0x1, 0x1, 0x0, 0xffffffff, ...) /root/go/src/cmd/go/main.go:305 +0x2f8 fp=0x50626c04 main.importPaths(0x30620018, 0x1, 0x1, 0x3, 0x0, ...) /root/go/src/cmd/go/main.go:315 +0x44 fp=0x50626c88 main.packagesAndErrors(0x30620018, 0x1, 0x1, 0x50626d60, 0x90f44, ...) /root/go/src/cmd/go/pkg.go:798 +0x1bc fp=0x50626d1c main.packagesForBuild(0x30620018, 0x1, 0x1, 0x53490, 0x0, ...) /root/go/src/cmd/go/pkg.go:818 +0x44 fp=0x50626dac main.runInstall(0x3e46e0, 0x30620018, 0x1, 0x1) /root/go/src/cmd/go/build.go:311 +0x48 fp=0x50626e60 main.main() /root/go/src/cmd/go/main.go:161 +0x518 fp=0x50626f8c runtime.main() /root/go/src/pkg/runtime/proc.c:222 +0x100 fp=0x50626fc0 runtime.goexit() /root/go/src/pkg/runtime/proc.c:1396 fp=0x50626fc0 goroutine 3 [syscall]: os/signal.loop() /root/go/src/pkg/os/signal/signal_unix.go:21 +0x24 created by os/signal.init·1 /root/go/src/pkg/os/signal/signal_unix.go:27 +0x48 R=minux.ma, rsc CC=golang-dev https://golang.org/cl/13824044
2013-09-23runtime/pprof: fix profile parser in testRuss Cox
Fixes #6417. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/13843043
2013-09-23undo CL 13321048 / 9567c5da6e25Russ Cox
Makes build unnecessarily slower. Will fix the parser instead. ««« original CL description runtime/pprof: run TestGoroutineSwitch for longer Short test now takes about 0.5 second here. Fixes #6417. The failure was also seen on our builders. R=golang-dev, minux.ma, r CC=golang-dev https://golang.org/cl/13321048 »»» R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/13720048
2013-09-22runtime/race: update runtime to r191161.Dmitriy Vyukov
Fixes #6305. R=golang-dev, dave, alex.brainman, r CC=golang-dev https://golang.org/cl/13359046
2013-09-22runtime/pprof: run TestGoroutineSwitch for longerAlex Brainman
Short test now takes about 0.5 second here. Fixes #6417. The failure was also seen on our builders. R=golang-dev, minux.ma, r CC=golang-dev https://golang.org/cl/13321048
2013-09-20runtime: avoid allocation of internal panic valuesRuss Cox
If a fault happens in malloc, inevitably the next thing that happens is a deadlock trying to allocate the panic value that says the fault happened. Stop doing that, two ways. First, reject panic in malloc just as we reject panic in garbage collection. Second, runtime.panicstring was using an error implementation backed by a Go string, so the interface held an allocated *string. Since the actual errors are C strings, define a new error implementation backed by a C char*, which needs no indirection and therefore no allocation. This second fix will avoid allocation for errors like nil panic derefs or division by zero, so it is worth doing even though the first fix should take care of faults during malloc. Update #6419 R=golang-dev, dvyukov, dave CC=golang-dev https://golang.org/cl/13774043
2013-09-19cmd/gc: cleanup SWITCH nodes after walk.Rémy Oudompheng
Keeping pointers from the pre-walk phase confuses the race detection instrumentation. Fixes #6418. R=golang-dev, dvyukov, r CC=golang-dev https://golang.org/cl/13368057
2013-09-16runtime: export PCDATA value readerCarl Shapiro
This interface is required to use the PCDATA interface implemented in Go 1.2. While initially entirely private, the FUNCDATA side of the interface has been made public. This change completes the FUNCDATA/PCDATA interface. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/13735043
2013-09-16cmd/gc, runtime: inline append in frontend.Rémy Oudompheng
A new transformation during walk turns append calls into a combination of growslice and memmove. benchmark old ns/op new ns/op delta BenchmarkAppend 141 141 +0.00% BenchmarkAppend1Byte 18 11 -39.56% BenchmarkAppend4Bytes 19 10 -42.63% BenchmarkAppend7Bytes 18 10 -42.16% BenchmarkAppend8Bytes 18 10 -40.44% BenchmarkAppend15Bytes 19 11 -41.67% BenchmarkAppend16Bytes 19 11 -41.97% BenchmarkAppend32Bytes 23 14 -38.82% BenchmarkAppendStr1Byte 14 10 -23.78% BenchmarkAppendStr4Bytes 14 11 -21.13% BenchmarkAppendStr8Bytes 14 10 -25.17% BenchmarkAppendStr16Bytes 19 11 -41.45% BenchmarkAppendStr32Bytes 18 14 -19.44% BenchmarkAppendSpecialCase 62 63 +1.77% R=golang-dev, khr, cshapiro, rsc, dave CC=golang-dev https://golang.org/cl/12815046
2013-09-16build: disable precise collection of stack framesRuss Cox
The code for call site-specific pointer bitmaps was not ready in time, but the zeroing required without it is too expensive to use by default. We will have to wait for precise collection of stack frames until Go 1.3. The precise collection can be re-enabled by GOEXPERIMENT=precisestack ./all.bash but that will not be the default for a Go 1.2 build. Fixes #6087. R=golang-dev, jeremyjackins, dan.kortschak, r CC=golang-dev https://golang.org/cl/13677045
2013-09-16runtime: fix uint64 division on 386Russ Cox
The uint64 divide function calls _mul64x32 to do a 64x32-bit multiply and then compares the result against the 64-bit numerator. If the result is bigger than the numerator, must use the slow path. Unfortunately, the 64x32 produces a 96-bit product, and only the low 64 bits were being used in the comparison. Return all 96 bits, the bottom 64 via the original uint64* pointer, and the top 32 as the function's return value. Fixes 386 build (broken by ARM division tests). R=golang-dev, iant CC=golang-dev https://golang.org/cl/13722044
2013-09-16runtime: fix freebsd buildRuss Cox
TBR=golang-dev CC=golang-dev https://golang.org/cl/13720044
2013-09-16cmd/cgo: allow C.malloc(0) alwaysRuss Cox
Because we can, and because it otherwise might crash the program if we think we're out of memory. Fixes #6390. R=golang-dev, iant, minux.ma CC=golang-dev https://golang.org/cl/13345048
2013-09-16runtime: make ARM integer div-by-zero traceback-friendlyRuss Cox
The implementation of division in the 5 toolchain is a bit too magical. Hide the magic from the traceback routines. Also add a test for the results of the software divide routine. Fixes #5805. R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/13239052
2013-09-16runtime, syscall: work around FreeBSD/amd64 kernel bugRuss Cox
The kernel implementation of the fast system call path, the one invoked by the SYSCALL instruction, is broken for restarting system calls. A C program demonstrating this is below. Change the system calls to use INT $0x80 instead, because that (perhaps slightly slower) system call path actually works. I filed http://www.freebsd.org/cgi/query-pr.cgi?pr=182161. The C program demonstrating that it is FreeBSD's fault is below. It reports the same "Bad address" failures from wait. #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*); int main(void) { int i; 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(SIGCHLD, &sa, 0); for(i=0; i<2; i++) pthread_create(0, 0, looper, 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) { } int mywait4(int pid, int *stat, int options, struct rusage *rusage) { int result; asm("movq %%rcx, %%r10; syscall" : "=a" (result) : "a" (7), "D" (pid), "S" (stat), "d" (options), "c" (rusage)); } static void* looper(void *v) { int pid, stat, out; struct rusage rusage; for(;;) { if((pid = fork()) == 0) _exit(0); out = mywait4(pid, &stat, 0, &rusage); if(out != pid) { printf("wait4 returned %d\n", out); } } } Fixes #6372. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/13582047
2013-09-15runtime: fix CPU profiling on WindowsRuss Cox
The test 'gp == m->curg' is not valid on Windows, because the goroutine being profiled is not from the current m. TBR=golang-dev CC=golang-dev https://golang.org/cl/13718043
2013-09-13runtime: avoid inconsistent goroutine state in profilerRuss Cox
Because profiling signals can arrive at any time, we must handle the case where a profiling signal arrives halfway through a goroutine switch. Luckily, although there is much to think through, very little needs to change. Fixes #6000. Fixes #6015. R=golang-dev, dvyukov CC=golang-dev https://golang.org/cl/13421048
2013-09-12runtime, cmd/gc, cmd/ld: ignore method wrappers in recoverRuss Cox
Bug #1: Issue 5406 identified an interesting case: defer iface.M() may end up calling a wrapper that copies an indirect receiver from the iface value and then calls the real M method. That's two calls down, not just one, and so recover() == nil always in the real M method, even during a panic. [For the purposes of this entire discussion, a wrapper's implementation is a function containing an ordinary call, not the optimized tail call form that is somtimes possible. The tail call does not create a second frame, so it is already handled correctly.] Fix this bug by introducing g->panicwrap, which counts the number of bytes on current stack segment that are due to wrapper calls that should not count against the recover check. All wrapper functions must now adjust g->panicwrap up on entry and back down on exit. This adds slightly to their expense; on the x86 it is a single instruction at entry and exit; on the ARM it is three. However, the alternative is to make a call to recover depend on being able to walk the stack, which I very much want to avoid. We have enough problems walking the stack for garbage collection and profiling. Also, if performance is critical in a specific case, it is already faster to use a pointer receiver and avoid this kind of wrapper entirely. Bug #2: The old code, which did not consider the possibility of two calls, already contained a check to see if the call had split its stack and so the panic-created segment was one behind the current segment. In the wrapper case, both of the two calls might split their stacks, so the panic-created segment can be two behind the current segment. Fix this by propagating the Stktop.panic flag forward during stack splits instead of looking backward during recover. Fixes #5406. R=golang-dev, iant CC=golang-dev https://golang.org/cl/13367052
2013-09-12cmd/gc: inline copy in frontend to call memmove directly.Rémy Oudompheng
A new node type OSPTR is added to refer to the data pointer of strings and slices in a simple way during walk(). It will be useful for future work on simplification of slice arithmetic. benchmark old ns/op new ns/op delta BenchmarkCopy1Byte 9 8 -13.98% BenchmarkCopy2Byte 14 8 -40.49% BenchmarkCopy4Byte 13 8 -35.04% BenchmarkCopy8Byte 13 8 -37.10% BenchmarkCopy12Byte 14 12 -15.38% BenchmarkCopy16Byte 14 12 -17.24% BenchmarkCopy32Byte 19 14 -27.32% BenchmarkCopy128Byte 31 26 -15.29% BenchmarkCopy1024Byte 100 92 -7.50% BenchmarkCopy1String 10 7 -28.99% BenchmarkCopy2String 10 7 -28.06% BenchmarkCopy4String 10 8 -22.69% BenchmarkCopy8String 10 8 -23.30% BenchmarkCopy12String 11 11 -5.88% BenchmarkCopy16String 11 11 -5.08% BenchmarkCopy32String 15 14 -6.58% BenchmarkCopy128String 28 25 -10.60% BenchmarkCopy1024String 95 95 +0.53% R=golang-dev, bradfitz, cshapiro, dave, daniel.morsing, rsc, khr, khr CC=golang-dev https://golang.org/cl/9101048
2013-09-11runtime: keep args and frame in struct FuncRuss Cox
args is useful for printing tracebacks. frame is not necessary anymore, but we might some day get back to functions where the frame size does not vary by program counter, and if so we'll need it. Avoid needing to introduce a new struct format later by keeping it now. Fixes #5907. R=golang-dev, iant CC=golang-dev https://golang.org/cl/13632051
2013-09-11runtime: show m stack during crash on m stackRuss Cox
The various throwing > 0 finish a change started in a previous CL, which sets throwing = -1 to mean "don't show the internals". That gets set during the "all goroutines are asleep - deadlock!" crash, and it should also be set during any other expected crash that does not indicate a problem within the runtime. Most runtime.throw do indicate a problem within the runtime, however, so we should be able to enumerate the ones that should be silent. The goroutine sleeping deadlock is the only one I can think of. Update #5139 R=golang-dev, iant CC=golang-dev https://golang.org/cl/13662043
2013-09-11runtime: show runtime.panic frame in tracebackRuss Cox
Otherwise, if panic starts running deferred functions, the code that panicked appears to be calling those functions directly, which is not the case and can be confusing. For example: main.Two() /Users/rsc/x.go:12 +0x2a runtime.panic(0x20dc0, 0x2100cc010) /Users/rsc/g/go/src/pkg/runtime/panic.c:248 +0x106 main.One() /Users/rsc/x.go:8 +0x55 This makes clear(er) that main.Two is being called during a panic, not as a direct call from main.One. Fixes #5832. R=golang-dev, iant CC=golang-dev https://golang.org/cl/13302051
2013-09-11cmd/cgo: replace C.malloc with our own wrapperRuss Cox
This allows us to make two changes: 1. Force the argument type to be size_t, even on broken systems that declare malloc to take a ulong. 2. Call runtime.throw if malloc fails. (That is, the program crashes; it does not panic.) Fixes #3403. Fixes #5926. R=golang-dev, iant CC=golang-dev https://golang.org/cl/13413047
2013-09-10runtime: explicit init of runtime-gdb helpersAlexis Imperial-Legrand
If using other gdb python scripts loaded before Go's gdb-runtime.py and that have a different init prototype: Traceback (most recent call last): File "/usr/lib/go/src/pkg/runtime/runtime-gdb.py", line 446, in <module> k() TypeError: __init__() takes exactly 3 arguments (1 given) The problem is that gdb keeps all python scripts in the same namespace, so vars() contains them. To avoid that, load helpers one by one. R=iant, rsc CC=gobot, golang-dev https://golang.org/cl/9752044
2013-09-10runtime: clean up / align comment tabbingKeith Randall
R=golang-dev, r CC=golang-dev https://golang.org/cl/13336046
2013-09-09runtime: remove OABI check from ARM startupRuss Cox
The code in question is trying to print a nice error message when a Go EABI binary runs on an OABI machine. Unfortunately, the only way to do that is to use ARM Thumb instructions, which we otherwise don't use. There exist ARM EABI machines that do not support Thumb. We could run on them if not for this OABI check, so disable it. Fixes #5685. R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/13234050
2013-09-09runtime: unbreak build on dragonflyJoel Sing
Update dragonfly memory functions to work with new memory statistics. R=golang-dev, iant CC=golang-dev https://golang.org/cl/13615043
2013-09-06runtime: Smhasher tests of our map hash function.Keith Randall
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/13436045
2013-09-06runtime: account for all sys memory in MemStatsDmitriy Vyukov
Currently lots of sys allocations are not accounted in any of XxxSys, including GC bitmap, spans table, GC roots blocks, GC finalizer blocks, iface table, netpoll descriptors and more. Up to ~20% can unaccounted. This change introduces 2 new stats: GCSys and OtherSys for GC metadata and all other misc allocations, respectively. Also ensures that all XxxSys indeed sum up to Sys. All sys memory allocation functions require the stat for accounting, so that it's impossible to miss something. Also fix updating of mcache_sys/inuse, they were not updated after deallocation. test/bench/garbage/parser before: Sys 670064344 HeapSys 610271232 StackSys 65536 MSpanSys 14204928 MCacheSys 16384 BuckHashSys 1439992 after: Sys 670064344 HeapSys 610271232 StackSys 65536 MSpanSys 14188544 MCacheSys 16384 BuckHashSys 3194304 GCSys 39198688 OtherSys 3129656 Fixes #5799. R=rsc, dave, alex.brainman CC=golang-dev https://golang.org/cl/12946043
2013-09-06runtime: handle timer overflow in tsleepAnthony Martin
Make sure we never pass a timer into timerproc with a negative duration since it will cause other timers to never expire. Fixes #5321. R=golang-dev, minux.ma, remyoudompheng, mikioh.mikioh, r, bradfitz, rsc, dvyukov CC=golang-dev https://golang.org/cl/9035047
2013-09-04cgo: enable cgo on dragonflyAulus Egnatius Varialus
Enable cgo for dragonfly/386 and dragonfly/amd64. R=golang-dev, jsing, iant, bradfitz CC=golang-dev https://golang.org/cl/13247046
2013-08-31runtime: clean up map code. Remove hashmap.h.Keith Randall
Use cnew/cnewarray instead of mallocgc. R=golang-dev, dvyukov CC=golang-dev https://golang.org/cl/13396045
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 17:08:08 +0000