aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime/malloc.goc
AgeCommit message (Collapse)Author
2012-01-10runtime: fix typo in commentMaxim Pimenov
R=golang-dev CC=golang-dev https://golang.org/cl/5529059
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-10-16runtime: fix crash if user sets MemProfileRate=0Dmitriy Vyukov
R=golang-dev, r CC=golang-dev https://golang.org/cl/5284044
2011-10-13gc: pass FlagNoPointers to runtime.newDmitriy Vyukov
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5151043
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-10-06runtime: fix malloc sampling bugRuss Cox
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
2011-08-31runtime: make arm work on Ubuntu Natty qemuRuss Cox
R=golang-dev, r CC=golang-dev https://golang.org/cl/4963050
2011-07-18runtime: add per-M caches for MemStatsDmitriy Vyukov
Avoid touching centralized state during memory manager opreations. R=rsc CC=golang-dev https://golang.org/cl/4766042
2011-07-12runtime: eliminate contention during stack allocationDmitriy Vyukov
Standard-sized stack frames use plain malloc/free instead of centralized lock-protected FixAlloc. 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 BenchmarkStackGrowth 1045.00 949.00 -9.19% BenchmarkStackGrowth-2 3450.00 800.00 -76.81% BenchmarkStackGrowth-4 5076.00 513.00 -89.89% BenchmarkStackGrowth-8 7805.00 471.00 -93.97% BenchmarkStackGrowth-16 11751.00 321.00 -97.27% R=golang-dev, rsc CC=golang-dev https://golang.org/cl/4657091
2011-07-12runtime: eliminate false sharing on random number generatorsDmitriy Vyukov
Use machine-local random number generator instead of racy global ones. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/4674049
2011-06-17gc: unsafe.Alignof, unsafe.Offsetof, unsafe.Sizeof now return uintptrRuss Cox
R=ken2 CC=golang-dev https://golang.org/cl/4640045
2011-05-10runtime: add newline to "finalizer already set" errorAlbert Strasheim
R=rsc, bradfitz CC=golang-dev https://golang.org/cl/4523047
2011-04-27runtime: allow use of >512 MB on 32-bit platformsRuss Cox
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
2011-02-23runtime: always run stackalloc on scheduler stackRuss Cox
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
2011-02-22ld: detect stack overflow due to NOSPLITRuss Cox
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
2011-02-16runtime: fix memory allocator for GOMAXPROCS > 1Russ Cox
Bitmaps were not being updated safely. Depends on 4188053. Fixes #1504. May fix issue 1479. R=r, r2 CC=golang-dev https://golang.org/cl/4184048
2011-02-11runtime: check that SysReserve returns aligned memoryRuss Cox
R=iant, iant2 CC=golang-dev https://golang.org/cl/4180043
2011-02-09runtime: fix memory allocation on 386Russ Cox
BSD and Darwin require an extra page between end and the first mapping, and Windows has various memory in the way too. Fixes #1464. R=r, r2 CC=golang-dev https://golang.org/cl/4167041
2011-02-02runtime: faster allocator, garbage collectorRuss Cox
GC is still single-threaded. Multiple threads will happen in another CL. Garbage collection pauses are typically about half as long as they were before this CL. R=brainman, iant, r CC=golang-dev https://golang.org/cl/3975046
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
2010-12-13gc: align structs according to max alignment of fieldsRuss Cox
cc: same runtime: test cc alignment (required moving #define of offsetof to runtime.h) fix bug260 Fixes #482. Fixes #609. R=ken2, r CC=golang-dev https://golang.org/cl/3563042
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-09-30runtime: serialize mcache allocationRuss Cox
Fixes racy regex-dna-parallel crashes. R=r, r2 CC=golang-dev https://golang.org/cl/2308042
2010-09-28runtime: add mmap of null page just in caseRuss Cox
R=r, iant, robert.swiecki, rsc1 CC=golang-dev https://golang.org/cl/1904044
2010-06-21runtime: split extern.go into debug.go, extern.go, sig.go.Russ Cox
move mal next to the other malloc functions. R=r CC=golang-dev https://golang.org/cl/1701045
2010-04-20runtime: rename cgo2c, *.cgo to goc2c, *.gocRuss Cox
to avoid confusion with real cgo R=r CC=golang-dev https://golang.org/cl/904046
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 15:50:51 +0000