aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime/amd64
AgeCommit message (Collapse)Author
2011-12-16runtime: make more build-friendlyRuss Cox
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
2011-12-07ld: increase default stack size on Windows for cgoDmitriy Vyukov
Fixes #2437. R=rsc, hectorchu, mattn.jp, alex.brainman, jdpoirier, snaury, n13m3y3r CC=golang-dev https://golang.org/cl/5371049
2011-11-09cgo: fix g0 stack guardDmitriy Vyukov
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
2011-10-27runtime: lock the main goroutine to the main OS thread during initRuss Cox
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
2011-10-13runtime: run goroutines during initRuss Cox
Fixes #583. Fixes #1776. Fixes #2001. Fixes #2112. R=golang-dev, bradfitz, r, gri CC=golang-dev https://golang.org/cl/5265044
2011-10-06runtime: faster finalizersDmitriy Vyukov
Linux/amd64, 2 x Intel Xeon E5620, 8 HT cores, 2.40GHz benchmark old ns/op new ns/op delta BenchmarkFinalizer 420.00 261.00 -37.86% BenchmarkFinalizer-2 985.00 201.00 -79.59% BenchmarkFinalizer-4 1077.00 244.00 -77.34% BenchmarkFinalizer-8 1155.00 180.00 -84.42% BenchmarkFinalizer-16 1182.00 184.00 -84.43% BenchmarkFinalizerRun 2128.00 1378.00 -35.24% BenchmarkFinalizerRun-2 1655.00 1418.00 -14.32% BenchmarkFinalizerRun-4 1634.00 1522.00 -6.85% BenchmarkFinalizerRun-8 2213.00 1581.00 -28.56% BenchmarkFinalizerRun-16 2424.00 1599.00 -34.03% Darwin/amd64, Intel L9600, 2 cores, 2.13GHz benchmark old ns/op new ns/op delta BenchmarkChanCreation 1451.00 926.00 -36.18% BenchmarkChanCreation-2 3124.00 1412.00 -54.80% BenchmarkChanCreation-4 6121.00 2628.00 -57.07% BenchmarkFinalizer 684.00 420.00 -38.60% BenchmarkFinalizer-2 11195.00 398.00 -96.44% BenchmarkFinalizer-4 15862.00 654.00 -95.88% BenchmarkFinalizerRun 2025.00 1397.00 -31.01% BenchmarkFinalizerRun-2 3920.00 1447.00 -63.09% BenchmarkFinalizerRun-4 9471.00 1545.00 -83.69% R=golang-dev, cw, rsc CC=golang-dev https://golang.org/cl/4963057
2011-08-29runtime: add runtime· prefix to showframeRuss Cox
R=ken2 CC=golang-dev https://golang.org/cl/4978042
2011-08-26cgo: fixes callback for windows amd64Wei Guangjing
R=rsc CC=golang-dev https://golang.org/cl/4826041
2011-08-22runtime: simplify stack tracesRuss Cox
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
2011-08-18runtime: speed up cgo callsAlex Brainman
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
2011-07-29runtime: fix data race in findfunc()Dmitriy Vyukov
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
2011-07-29runtime: improve Linux mutexDmitriy Vyukov
The implementation is hybrid active/passive spin/blocking mutex. The design minimizes amount of context switches and futex calls. The idea is that all critical sections in runtime are intentially small, so pure blocking mutex behaves badly causing a lot of context switches, thread parking/unparking and kernel calls. Note that some synthetic benchmarks become somewhat slower, that's due to increased contention on other data structures, it should not affect programs that do any real work. On 2 x Intel E5620, 8 HT cores, 2.4GHz benchmark old ns/op new ns/op delta BenchmarkSelectContended 521.00 503.00 -3.45% BenchmarkSelectContended-2 661.00 320.00 -51.59% BenchmarkSelectContended-4 1139.00 629.00 -44.78% BenchmarkSelectContended-8 2870.00 878.00 -69.41% BenchmarkSelectContended-16 5276.00 818.00 -84.50% BenchmarkChanContended 112.00 103.00 -8.04% BenchmarkChanContended-2 631.00 174.00 -72.42% BenchmarkChanContended-4 682.00 272.00 -60.12% BenchmarkChanContended-8 1601.00 520.00 -67.52% BenchmarkChanContended-16 3100.00 372.00 -88.00% BenchmarkChanSync 253.00 239.00 -5.53% BenchmarkChanSync-2 5030.00 4648.00 -7.59% BenchmarkChanSync-4 4826.00 4694.00 -2.74% BenchmarkChanSync-8 4778.00 4713.00 -1.36% BenchmarkChanSync-16 5289.00 4710.00 -10.95% BenchmarkChanProdCons0 273.00 254.00 -6.96% BenchmarkChanProdCons0-2 599.00 400.00 -33.22% BenchmarkChanProdCons0-4 1168.00 659.00 -43.58% BenchmarkChanProdCons0-8 2831.00 1057.00 -62.66% BenchmarkChanProdCons0-16 4197.00 1037.00 -75.29% BenchmarkChanProdCons10 150.00 140.00 -6.67% BenchmarkChanProdCons10-2 607.00 268.00 -55.85% BenchmarkChanProdCons10-4 1137.00 404.00 -64.47% BenchmarkChanProdCons10-8 2115.00 828.00 -60.85% BenchmarkChanProdCons10-16 4283.00 855.00 -80.04% BenchmarkChanProdCons100 117.00 110.00 -5.98% BenchmarkChanProdCons100-2 558.00 218.00 -60.93% BenchmarkChanProdCons100-4 722.00 287.00 -60.25% BenchmarkChanProdCons100-8 1840.00 431.00 -76.58% BenchmarkChanProdCons100-16 3394.00 448.00 -86.80% BenchmarkChanProdConsWork0 2014.00 1996.00 -0.89% BenchmarkChanProdConsWork0-2 1207.00 1127.00 -6.63% BenchmarkChanProdConsWork0-4 1913.00 611.00 -68.06% BenchmarkChanProdConsWork0-8 3016.00 949.00 -68.53% BenchmarkChanProdConsWork0-16 4320.00 1154.00 -73.29% BenchmarkChanProdConsWork10 1906.00 1897.00 -0.47% BenchmarkChanProdConsWork10-2 1123.00 1033.00 -8.01% BenchmarkChanProdConsWork10-4 1076.00 571.00 -46.93% BenchmarkChanProdConsWork10-8 2748.00 1096.00 -60.12% BenchmarkChanProdConsWork10-16 4600.00 1105.00 -75.98% BenchmarkChanProdConsWork100 1884.00 1852.00 -1.70% BenchmarkChanProdConsWork100-2 1235.00 1146.00 -7.21% BenchmarkChanProdConsWork100-4 1217.00 619.00 -49.14% BenchmarkChanProdConsWork100-8 1534.00 509.00 -66.82% BenchmarkChanProdConsWork100-16 4126.00 918.00 -77.75% BenchmarkSyscall 34.40 33.30 -3.20% BenchmarkSyscall-2 160.00 121.00 -24.38% BenchmarkSyscall-4 131.00 136.00 +3.82% BenchmarkSyscall-8 139.00 131.00 -5.76% BenchmarkSyscall-16 161.00 168.00 +4.35% BenchmarkSyscallWork 950.00 950.00 +0.00% BenchmarkSyscallWork-2 481.00 480.00 -0.21% BenchmarkSyscallWork-4 268.00 270.00 +0.75% BenchmarkSyscallWork-8 156.00 169.00 +8.33% BenchmarkSyscallWork-16 188.00 184.00 -2.13% BenchmarkSemaSyntNonblock 36.40 35.60 -2.20% BenchmarkSemaSyntNonblock-2 81.40 45.10 -44.59% BenchmarkSemaSyntNonblock-4 126.00 108.00 -14.29% BenchmarkSemaSyntNonblock-8 112.00 112.00 +0.00% BenchmarkSemaSyntNonblock-16 110.00 112.00 +1.82% BenchmarkSemaSyntBlock 35.30 35.30 +0.00% BenchmarkSemaSyntBlock-2 118.00 124.00 +5.08% BenchmarkSemaSyntBlock-4 105.00 108.00 +2.86% BenchmarkSemaSyntBlock-8 101.00 111.00 +9.90% BenchmarkSemaSyntBlock-16 112.00 118.00 +5.36% BenchmarkSemaWorkNonblock 810.00 811.00 +0.12% BenchmarkSemaWorkNonblock-2 476.00 414.00 -13.03% BenchmarkSemaWorkNonblock-4 238.00 228.00 -4.20% BenchmarkSemaWorkNonblock-8 140.00 126.00 -10.00% BenchmarkSemaWorkNonblock-16 117.00 116.00 -0.85% BenchmarkSemaWorkBlock 810.00 811.00 +0.12% BenchmarkSemaWorkBlock-2 454.00 466.00 +2.64% BenchmarkSemaWorkBlock-4 243.00 241.00 -0.82% BenchmarkSemaWorkBlock-8 145.00 137.00 -5.52% BenchmarkSemaWorkBlock-16 132.00 123.00 -6.82% BenchmarkContendedSemaphore 123.00 102.00 -17.07% BenchmarkContendedSemaphore-2 34.80 34.90 +0.29% BenchmarkContendedSemaphore-4 34.70 34.80 +0.29% BenchmarkContendedSemaphore-8 34.70 34.70 +0.00% BenchmarkContendedSemaphore-16 34.80 34.70 -0.29% BenchmarkMutex 26.80 26.00 -2.99% BenchmarkMutex-2 108.00 45.20 -58.15% BenchmarkMutex-4 103.00 127.00 +23.30% BenchmarkMutex-8 109.00 147.00 +34.86% BenchmarkMutex-16 102.00 152.00 +49.02% BenchmarkMutexSlack 27.00 26.90 -0.37% BenchmarkMutexSlack-2 149.00 165.00 +10.74% BenchmarkMutexSlack-4 121.00 209.00 +72.73% BenchmarkMutexSlack-8 101.00 158.00 +56.44% BenchmarkMutexSlack-16 97.00 129.00 +32.99% BenchmarkMutexWork 792.00 794.00 +0.25% BenchmarkMutexWork-2 407.00 409.00 +0.49% BenchmarkMutexWork-4 220.00 209.00 -5.00% BenchmarkMutexWork-8 267.00 160.00 -40.07% BenchmarkMutexWork-16 315.00 300.00 -4.76% BenchmarkMutexWorkSlack 792.00 793.00 +0.13% BenchmarkMutexWorkSlack-2 406.00 404.00 -0.49% BenchmarkMutexWorkSlack-4 225.00 212.00 -5.78% BenchmarkMutexWorkSlack-8 268.00 136.00 -49.25% BenchmarkMutexWorkSlack-16 300.00 300.00 +0.00% BenchmarkRWMutexWrite100 27.10 27.00 -0.37% BenchmarkRWMutexWrite100-2 33.10 40.80 +23.26% BenchmarkRWMutexWrite100-4 113.00 88.10 -22.04% BenchmarkRWMutexWrite100-8 119.00 95.30 -19.92% BenchmarkRWMutexWrite100-16 148.00 109.00 -26.35% BenchmarkRWMutexWrite10 29.60 29.40 -0.68% BenchmarkRWMutexWrite10-2 111.00 61.40 -44.68% BenchmarkRWMutexWrite10-4 270.00 208.00 -22.96% BenchmarkRWMutexWrite10-8 204.00 185.00 -9.31% BenchmarkRWMutexWrite10-16 261.00 190.00 -27.20% BenchmarkRWMutexWorkWrite100 1040.00 1036.00 -0.38% BenchmarkRWMutexWorkWrite100-2 593.00 580.00 -2.19% BenchmarkRWMutexWorkWrite100-4 470.00 365.00 -22.34% BenchmarkRWMutexWorkWrite100-8 468.00 289.00 -38.25% BenchmarkRWMutexWorkWrite100-16 604.00 374.00 -38.08% BenchmarkRWMutexWorkWrite10 951.00 951.00 +0.00% BenchmarkRWMutexWorkWrite10-2 1001.00 928.00 -7.29% BenchmarkRWMutexWorkWrite10-4 1555.00 1006.00 -35.31% BenchmarkRWMutexWorkWrite10-8 2085.00 1171.00 -43.84% BenchmarkRWMutexWorkWrite10-16 2082.00 1614.00 -22.48% R=rsc, iant, msolo, fw, iant CC=golang-dev https://golang.org/cl/4711045
2011-07-26gc, runtime: fix range+panic line number bugsRuss Cox
Fixes #1856. R=ken2 CC=golang-dev https://golang.org/cl/4810054
2011-07-23runtime: replace byte-at-a-time zeroing loop with memclrQuan Yong Zhai
R=golang-dev, r, r, dsymonds, rsc CC=golang-dev https://golang.org/cl/4813043
2011-07-19cgo: windows amd64 portWei Guangjing
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/4725041
2011-07-15runtime: native xadd for 386/amd64Dmitriy Vyukov
benchmark old ns/op new ns/op delta BenchmarkSemaUncontended 37.40 34.10 -8.82% BenchmarkSemaUncontended-2 18.90 17.70 -6.35% BenchmarkSemaUncontended-4 11.90 10.90 -8.40% BenchmarkSemaUncontended-8 6.26 5.19 -17.09% BenchmarkSemaUncontended-16 4.39 3.91 -10.93% BenchmarkSemaSyntNonblock 38.00 35.30 -7.11% BenchmarkSemaSyntNonblock-2 83.00 46.70 -43.73% BenchmarkSemaSyntNonblock-4 124.00 101.00 -18.55% BenchmarkSemaSyntNonblock-8 124.00 116.00 -6.45% BenchmarkSemaSyntNonblock-16 148.00 114.00 -22.97% (on HP Z600 2 x Xeon E5620, 8 HT cores, 2.40GHz) R=golang-dev, rsc CC=golang-dev https://golang.org/cl/4755041
2011-07-13runtime: fix data race during Itab hash update/lookupDmitriy Vyukov
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
2011-07-12runtime: replace runtime.mcpy with runtime.memmoveQuan Yong Zhai
faster string operations, and more tested on linux/386 runtime_test.BenchmarkSliceToString 642 532 -17.13% runtime_test.BenchmarkStringToSlice 636 528 -16.98% runtime_test.BenchmarkConcatString 1109 897 -19.12% R=r, iant, rsc CC=golang-dev https://golang.org/cl/4674042
2011-06-28runtime: replace Semacquire/Semrelease implementationDmitriy Vyukov
1. The implementation uses distributed hash table of waitlists instead of a centralized one. It significantly improves scalability for uncontended semaphores. 2. The implementation provides wait-free fast-path for signalers. 3. The implementation uses less locks (1 lock/unlock instead of 5 for Semacquire). 4. runtime·ready() call is moved out of critical section. 5. Semacquire() does not call semwake(). Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz) are as follows: benchmark old ns/op new ns/op delta runtime_test.BenchmarkSemaUncontended 58.20 36.30 -37.63% runtime_test.BenchmarkSemaUncontended-2 199.00 18.30 -90.80% runtime_test.BenchmarkSemaUncontended-4 327.00 9.20 -97.19% runtime_test.BenchmarkSemaUncontended-8 491.00 5.32 -98.92% runtime_test.BenchmarkSemaUncontended-16 946.00 4.18 -99.56% runtime_test.BenchmarkSemaSyntNonblock 59.00 36.80 -37.63% runtime_test.BenchmarkSemaSyntNonblock-2 167.00 138.00 -17.37% runtime_test.BenchmarkSemaSyntNonblock-4 333.00 129.00 -61.26% runtime_test.BenchmarkSemaSyntNonblock-8 464.00 130.00 -71.98% runtime_test.BenchmarkSemaSyntNonblock-16 1015.00 136.00 -86.60% runtime_test.BenchmarkSemaSyntBlock 58.80 36.70 -37.59% runtime_test.BenchmarkSemaSyntBlock-2 294.00 149.00 -49.32% runtime_test.BenchmarkSemaSyntBlock-4 333.00 177.00 -46.85% runtime_test.BenchmarkSemaSyntBlock-8 471.00 221.00 -53.08% runtime_test.BenchmarkSemaSyntBlock-16 990.00 227.00 -77.07% runtime_test.BenchmarkSemaWorkNonblock 829.00 832.00 +0.36% runtime_test.BenchmarkSemaWorkNonblock-2 425.00 419.00 -1.41% runtime_test.BenchmarkSemaWorkNonblock-4 308.00 220.00 -28.57% runtime_test.BenchmarkSemaWorkNonblock-8 394.00 147.00 -62.69% runtime_test.BenchmarkSemaWorkNonblock-16 1510.00 149.00 -90.13% runtime_test.BenchmarkSemaWorkBlock 828.00 813.00 -1.81% runtime_test.BenchmarkSemaWorkBlock-2 428.00 436.00 +1.87% runtime_test.BenchmarkSemaWorkBlock-4 232.00 219.00 -5.60% runtime_test.BenchmarkSemaWorkBlock-8 392.00 251.00 -35.97% runtime_test.BenchmarkSemaWorkBlock-16 1524.00 298.00 -80.45% sync_test.BenchmarkMutexUncontended 24.10 24.00 -0.41% sync_test.BenchmarkMutexUncontended-2 12.00 12.00 +0.00% sync_test.BenchmarkMutexUncontended-4 6.25 6.17 -1.28% sync_test.BenchmarkMutexUncontended-8 3.43 3.34 -2.62% sync_test.BenchmarkMutexUncontended-16 2.34 2.32 -0.85% sync_test.BenchmarkMutex 24.70 24.70 +0.00% sync_test.BenchmarkMutex-2 208.00 99.50 -52.16% sync_test.BenchmarkMutex-4 2744.00 256.00 -90.67% sync_test.BenchmarkMutex-8 5137.00 556.00 -89.18% sync_test.BenchmarkMutex-16 5368.00 1284.00 -76.08% sync_test.BenchmarkMutexSlack 24.70 25.00 +1.21% sync_test.BenchmarkMutexSlack-2 1094.00 186.00 -83.00% sync_test.BenchmarkMutexSlack-4 3430.00 402.00 -88.28% sync_test.BenchmarkMutexSlack-8 5051.00 1066.00 -78.90% sync_test.BenchmarkMutexSlack-16 6806.00 1363.00 -79.97% sync_test.BenchmarkMutexWork 793.00 792.00 -0.13% sync_test.BenchmarkMutexWork-2 398.00 398.00 +0.00% sync_test.BenchmarkMutexWork-4 1441.00 308.00 -78.63% sync_test.BenchmarkMutexWork-8 8532.00 847.00 -90.07% sync_test.BenchmarkMutexWork-16 8225.00 2760.00 -66.44% sync_test.BenchmarkMutexWorkSlack 793.00 793.00 +0.00% sync_test.BenchmarkMutexWorkSlack-2 418.00 414.00 -0.96% sync_test.BenchmarkMutexWorkSlack-4 4481.00 480.00 -89.29% sync_test.BenchmarkMutexWorkSlack-8 6317.00 1598.00 -74.70% sync_test.BenchmarkMutexWorkSlack-16 9111.00 3038.00 -66.66% R=rsc CC=golang-dev https://golang.org/cl/4631059
2011-06-09runtime: improve memmoveQuan Yong Zhai
check memory overlap R=rsc, r, ken, edsrzf CC=golang-dev https://golang.org/cl/4602047
2011-04-27runtime: stack split + garbage collection bugRuss Cox
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
2011-03-23runtime: cpu profiling supportRuss Cox
R=r CC=golang-dev https://golang.org/cl/4306043
2011-03-07runtime: scheduler, cgo reorganizationRuss Cox
* 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
2011-03-02runtime: record goroutine creation pc and display in tracebackRuss Cox
package main func main() { go func() { *(*int)(nil) = 0 }() select{} } panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0x1c96] runtime.panic+0xac /Users/rsc/g/go/src/pkg/runtime/proc.c:1083 runtime.panic(0x11bf0, 0xf8400011f0) runtime.panicstring+0xa3 /Users/rsc/g/go/src/pkg/runtime/runtime.c:116 runtime.panicstring(0x29a57, 0x0) runtime.sigpanic+0x144 /Users/rsc/g/go/src/pkg/runtime/darwin/thread.c:470 runtime.sigpanic() main._func_001+0x16 /Users/rsc/g/go/src/pkg/runtime/x.go:188 main._func_001() runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:150 runtime.goexit() ----- goroutine created by ----- main.main+0x3d /Users/rsc/g/go/src/pkg/runtime/x.go:4 goroutine 1 [4]: runtime.gosched+0x77 /Users/rsc/g/go/src/pkg/runtime/proc.c:598 runtime.gosched() runtime.block+0x27 /Users/rsc/g/go/src/pkg/runtime/chan.c:680 runtime.block() main.main+0x44 /Users/rsc/g/go/src/pkg/runtime/x.go:5 main.main() runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/amd64/asm.s:77 runtime.mainstart() runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:150 runtime.goexit() ----- goroutine created by ----- _rt0_amd64+0x8e /Users/rsc/g/go/src/pkg/runtime/amd64/asm.s:64 Fixes #1563. R=r CC=golang-dev https://golang.org/cl/4243046
2011-02-23runtime: traceback through active lessstackRuss Cox
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
2011-02-16runtime: minor cleanupRuss Cox
implement runtime.casp on amd64. keep simultaneous panic messages separate. R=r CC=golang-dev https://golang.org/cl/4188053
2011-02-02runtime: more detailed panic traces, line number workRuss Cox
Follow morestack, so that crashes during a stack split give complete traces. Also mark stack segment boundaries as an aid to debugging. Correct various line number bugs with yet another attempt at interpreting the pc/ln table. This one has a chance at being correct, because I based it on reading src/cmd/ld/lib.c instead of on reading the documentation. Fixes #1138. Fixes #1430. Fixes #1461. throw: runtime: split stack overflow runtime.throw+0x3e /home/rsc/g/go2/src/pkg/runtime/runtime.c:78 runtime.throw(0x81880af, 0xf75c8b18) runtime.newstack+0xad /home/rsc/g/go2/src/pkg/runtime/proc.c:728 runtime.newstack() runtime.morestack+0x4f /home/rsc/g/go2/src/pkg/runtime/386/asm.s:184 runtime.morestack() ----- morestack called from stack: ----- runtime.new+0x1a /home/rsc/g/go2/src/pkg/runtime/malloc.c:288 runtime.new(0x1, 0x0, 0x0) gongo.makeBoard+0x33 /tmp/Gongo/gongo_robot_test.go:344 gongo.makeBoard(0x809d238, 0x1, 0xf76092c8, 0x1) ----- stack segment boundary ----- gongo.checkEasyScore+0xcc /tmp/Gongo/gongo_robot_test.go:287 gongo.checkEasyScore(0xf764b710, 0x0, 0x809d238, 0x1) gongo.TestEasyScore+0x8c /tmp/Gongo/gongo_robot_test.go:255 gongo.TestEasyScore(0xf764b710, 0x818a990) testing.tRunner+0x2f /home/rsc/g/go2/src/pkg/testing/testing.go:132 testing.tRunner(0xf764b710, 0xf763b5dc, 0x0) runtime.goexit /home/rsc/g/go2/src/pkg/runtime/proc.c:149 runtime.goexit() R=ken2, r CC=golang-dev https://golang.org/cl/4000053
2011-01-28runtime: simpler heap map, memory allocationRuss Cox
The old heap maps used a multilevel table, but that was overkill: there are only 1M entries on a 32-bit machine and we can arrange to use a dense address range on a 64-bit machine. The heap map is in bss. The assumption is that if we don't touch the pages they won't be mapped in. Also moved some duplicated memory allocation code out of the OS-specific files. R=r CC=golang-dev https://golang.org/cl/4118042
2011-01-25runtime: prefer fixed stack allocator over general memory allocatorRuss Cox
* move stack constants from proc.c to runtime.h * make memclr take uintptr length R=r CC=golang-dev https://golang.org/cl/3985046
2011-01-14runtime: fix arm reflect.call boundary caseRuss Cox
The fault was lucky: when it wasn't faulting it was silently copying a word from some other block and later putting that same word back. If some other goroutine had changed that word of memory in the interim, too bad. The ARM code was inconsistent about whether the "argument frame" included the saved LR. Including it made some things more regular but mostly just caused confusion in the places where the regularity broke. Now the rule reflects reality: argp is always a pointer to arguments, never a saved link register. Renamed struct fields to make meaning clearer. Running ARM in QEMU, package time's gotest: * before: 27/58 failed * after: 0/50 R=r, r2 CC=golang-dev https://golang.org/cl/3993041
2010-11-04runtime: ,s/[a-zA-Z0-9_]+/runtime·&/g, almostRuss Cox
Prefix all external symbols in runtime by runtime·, to avoid conflicts with possible symbols of the same name in linked-in C libraries. The obvious conflicts are printf, malloc, and free, but hide everything to avoid future pain. The symbols left alone are: ** known to cgo ** _cgo_free _cgo_malloc libcgo_thread_start initcgo ncgocall ** known to linker ** _rt0_$GOARCH _rt0_$GOARCH_$GOOS text etext data end pclntab epclntab symtab esymtab ** known to C compiler ** _divv _modv _div64by32 etc (arch specific) Tested on darwin/386, darwin/amd64, linux/386, linux/amd64. Built (but not tested) for freebsd/386, freebsd/amd64, linux/arm, windows/386. R=r, PeterGo CC=golang-dev https://golang.org/cl/2899041
2010-10-07runtime: fix argument dump in tracebackRuss Cox
Was printing words at SP instead of at FP after shuffle due to nascent flag. R=r, r2 CC=golang-dev https://golang.org/cl/2316044
2010-09-09runtime: fix bug in tracebacksRob Pike
Need to correct for deferproc's extra 2 words of stack or in some cases (such as memory profiling) traceback can cause a crash. Also bulletproof the closure test. R=rsc CC=golang-dev https://golang.org/cl/2138047
2010-08-04amd64: use segment memory for thread-local storageRuss Cox
Returns R14 and R15 to the available register pool. Plays more nicely with ELF ABI C code. In particular, our signal handlers will no longer crash when a signal arrives during execution of a cgo C call. Fixes #720. R=ken2, r CC=golang-dev https://golang.org/cl/1847051
2010-05-21runtime: correct tracebacks for nascent goroutines, even closuresRuss Cox
Fixes #780. R=r CC=golang-dev https://golang.org/cl/1221042
2010-04-09Run initcgo for all amd64 targets, not just GNU/Linux.Ian Lance Taylor
This is required to make cgo export work on Darwin. Note that this corrects the stack alignment when calling initcgo to that required by gcc on amd64. R=rsc CC=golang-dev https://golang.org/cl/907041
2010-04-09Support cgo export on amd64.Ian Lance Taylor
R=rsc CC=golang-dev https://golang.org/cl/857045
2010-04-05runtime: various arm fixesRuss Cox
* correct symbol table size * do not reorder functions in output * traceback * signal handling * use same code for go + defer * handle leaf functions in symbol table R=kaib, dpx CC=golang-dev https://golang.org/cl/884041
2010-03-31runtime: make type assertion a runtime.Error, the first of manyRuss Cox
R=r CC=golang-dev https://golang.org/cl/805043
2010-03-30gc: add panic and recover (still unimplemented in runtime)Russ Cox
main semantic change is to enforce single argument to panic. runtime: change to 1-argument panic. use String method on argument if it has one. R=ken2, r CC=golang-dev https://golang.org/cl/812043
2010-03-29runtime: run deferred calls at GoexitRuss Cox
baby step toward panic+recover. Fixes #349. R=r CC=golang-dev https://golang.org/cl/825043
2010-03-23runtime: add CallersRuss Cox
cut copies of traceback from 6 to 1. R=r CC=golang-dev https://golang.org/cl/703041
2010-01-25in C and asm, replace pkg·name with ·nameRuss Cox
(eliminate assumption of package global name space, make code easier to move between packages). R=r CC=golang-dev https://golang.org/cl/194072
2009-12-08Fix stack on FreeBSD / add stack check across the boardDevon H. O'Dell
FreeBSD was passing stk as the new thread's stack base, while stk is the top of the stack in go. The added check should cause a trap if this ever comes up in any new ports, or regresses in current ones. R=rsc CC=golang-dev https://golang.org/cl/167055
2009-11-18bugs in memmove:Rob Pike
- has arguments (no stack split) - MOVL does not set condition R=ken2, rsc https://golang.org/cl/156086
2009-11-17copy tweaksRuss Cox
* move memmove to arch-specific subdirectories * add memmove for arm * add copyright notices marking them as copied from Inferno R=ken2 https://golang.org/cl/156061
2009-11-17FreeBSD-specific porting work.Devon H. O'Dell
cgo/libmach remain unimplemented. However, compilers, runtime, and packages are 100%. I still need to go through and implement missing syscalls (at least make sure they're all listed), but for all shipped functionality, this is done. Ship! ;) R=rsc, VenkateshSrinivas https://golang.org/cl/152142
2009-11-15runtime: avoid crash in CallerRuss Cox
Fixes #176. R=r https://golang.org/cl/154146
2009-10-15rename sys functions to runtime,Russ Cox
because they are in package runtime. another step to enforcing package boundaries. R=r DELTA=732 (114 added, 93 deleted, 525 changed) OCL=35811 CL=35824
2009-10-12stack overflow debugging and fix.Russ Cox
* in 6l, -K already meant check for stack underflow. add -KK to mean double-check stack overflows even in nosplit functions. * comment out print locks; they deadlock too easily but are still useful to put back for special occasions. * let runcgo assembly switch to scheduler stack without involving scheduler directly. because runcgo gets called from matchmg, it is too hard to keep it from being called on other stacks. R=r DELTA=94 (65 added, 18 deleted, 11 changed) OCL=35591 CL=35604
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 20:37:09 +0000