aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime/malloc.goc
AgeCommit message (Collapse)Author
2014-05-19runtime: fix freeOSMemory to free memory immediatelyDmitriy Vyukov
Currently freeOSMemory makes only marking phase of GC, but not sweeping phase. So recently memory is not released after freeOSMemory. Do both marking and sweeping during freeOSMemory. Fixes #8019. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, rsc https://golang.org/cl/97550043
2014-04-21runtime: fix typo in error messageMark Zavislak
LGTM=robert.hencke, iant R=golang-codereviews, robert.hencke, iant CC=golang-codereviews https://golang.org/cl/89760043
2014-04-02runtime: ignore pointers to global objects in SetFinalizerDmitriy Vyukov
Update #7656 LGTM=rsc R=rsc, iant CC=golang-codereviews https://golang.org/cl/82560043
2014-04-01runtime: adjust GODEBUG=allocfreetrace=1 and GODEBUG=gcdead=1Russ Cox
GODEBUG=allocfreetrace=1: The allocfreetrace=1 mode prints a stack trace for each block allocated and freed, and also a stack trace for each garbage collection. It was implemented by reusing the heap profiling support: if allocfreetrace=1 then the heap profile was effectively running at 1 sample per 1 byte allocated (always sample). The stack being shown at allocation was the stack gathered for profiling, meaning it was derived only from the program counters and did not include information about function arguments or frame pointers. The stack being shown at free was the allocation stack, not the free stack. If you are generating this log, you can find the allocation stack yourself, but it can be useful to see exactly the sequence that led to freeing the block: was it the garbage collector or an explicit free? Now that the garbage collector runs on an m0 stack, the stack trace for the garbage collector was never interesting. Fix all these problems: 1. Decouple allocfreetrace=1 from heap profiling. 2. Print the standard goroutine stack traces instead of a custom format. 3. Print the stack trace at time of allocation for an allocation, and print the stack trace at time of free (not the allocation trace again) for a free. 4. Print all goroutine stacks at garbage collection. Having all the stacks means that you can see the exact point at which each goroutine was preempted, which is often useful for identifying liveness-related errors. GODEBUG=gcdead=1: This mode overwrites dead pointers with a poison value. Detect the poison value as an invalid pointer during collection, the same way that small integers are invalid pointers. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81670043
2014-03-26runtime: fix yet another race in bgsweepDmitriy Vyukov
Currently it's possible that bgsweep finishes before all spans have been swept (we only know that sweeping of all spans has *started*). In such case bgsweep may fail wake up runfinq goroutine when it needs to. finq may still be nil at this point, but some finalizers may be queued later. Make bgsweep to wait for sweeping to *complete*, then it can decide whether it needs to wake up runfinq for sure. Update #7533 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/75960043
2014-03-25runtime: accurately record whether heap memory is reservedIan Lance Taylor
The existing code did not have a clear notion of whether memory has been actually reserved. It checked based on whether in 32-bit mode or 64-bit mode and (on GNU/Linux) the requested address, but it confused the requested address and the returned address. LGTM=rsc R=rsc, dvyukov CC=golang-codereviews, michael.hudson https://golang.org/cl/79610043
2014-03-06runtime: fix malloc page alignment + efenceRuss Cox
Two memory allocator bug fixes. - efence is not maintaining the proper heap metadata to make eventual memory reuse safe, so use SysFault. - now that our heap PageSize is 8k but most hardware uses 4k pages, SysAlloc and SysReserve results must be explicitly aligned. Do that in a few more call sites and document this fact in malloc.h. Fixes #7448. LGTM=iant R=golang-codereviews, josharian, iant CC=dvyukov, golang-codereviews https://golang.org/cl/71750048
2014-03-06runtime: use custom thunks for race calls instead of cgoDmitriy Vyukov
Implement custom assembly thunks for hot race calls (memory accesses and function entry/exit). The thunks extract caller pc, verify that the address is in heap or global and switch to g0 stack. Before: ok regexp 3.692s ok compress/bzip2 9.461s ok encoding/json 6.380s After: ok regexp 2.229s (-40%) ok compress/bzip2 4.703s (-50%) ok encoding/json 3.629s (-43%) For comparison, normal non-race build: ok regexp 0.348s ok compress/bzip2 0.304s ok encoding/json 0.661s Race build: ok regexp 2.229s (+540%) ok compress/bzip2 4.703s (+1447%) ok encoding/json 3.629s (+449%) Also removes some race-related special cases from cgocall and scheduler. In long-term it will allow to remove cyclic runtime/race dependency on cmd/cgo. Fixes #4249. Fixes #7460. Update #6508 Update #6688 R=iant, rsc, bradfitz CC=golang-codereviews https://golang.org/cl/55100044
2014-03-06runtime: fix runaway memory usageDmitriy Vyukov
It was caused by mstats.heap_alloc skew. Fixes #7430. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, rsc https://golang.org/cl/69870055
2014-03-04runtime: fix finalizer flakinessRuss Cox
The flakiness appears to be just in tests, not in the actual code. Specifically, the many tests call runtime.GC once and expect that the finalizers will be running in the background when GC returns. Now that the sweep phase is concurrent with execution, however, the finalizers will not be run until sweep finishes, which might be quite a bit later. To force sweep to finish, implement runtime.GC by calling the actual collection twice. The second will complete the sweep from the first. This was reliably broken after a few runs before the CL and now passes tens of runs: while GOMAXPROCS=2 ./runtime.test -test.run=Finalizer -test.short \ -test.timeout=300s -test.cpu=$(perl -e 'print ("1,2,4," x 100) . "1"') do true; done Fixes #7328. LGTM=dvyukov R=dvyukov, dave CC=golang-codereviews https://golang.org/cl/71080043
2014-02-26runtime: get rid of the settype buffer and lock.Keith Randall
MCaches now hold a MSpan for each sizeclass which they have exclusive access to allocate from, so no lock is needed. Modifying the heap bitmaps also no longer requires a cas. runtime.free gets more expensive. But we don't use it much any more. It's not much faster on 1 processor, but it's a lot faster on multiple processors. benchmark old ns/op new ns/op delta BenchmarkSetTypeNoPtr1 24 23 -0.42% BenchmarkSetTypeNoPtr2 33 34 +0.89% BenchmarkSetTypePtr1 51 49 -3.72% BenchmarkSetTypePtr2 55 54 -1.98% benchmark old ns/op new ns/op delta BenchmarkAllocation 52739 50770 -3.73% BenchmarkAllocation-2 33957 34141 +0.54% BenchmarkAllocation-3 33326 29015 -12.94% BenchmarkAllocation-4 38105 25795 -32.31% BenchmarkAllocation-5 68055 24409 -64.13% BenchmarkAllocation-6 71544 23488 -67.17% BenchmarkAllocation-7 68374 23041 -66.30% BenchmarkAllocation-8 70117 20758 -70.40% LGTM=rsc, dvyukov R=dvyukov, bradfitz, khr, rsc CC=golang-codereviews https://golang.org/cl/46810043
2014-02-20runtime: use goc2c as much as possibleRuss Cox
Package runtime's C functions written to be called from Go started out written in C using carefully constructed argument lists and the FLUSH macro to write a result back to memory. For some functions, the appropriate parameter list ended up being architecture-dependent due to differences in alignment, so we added 'goc2c', which takes a .goc file containing Go func declarations but C bodies, rewrites the Go func declaration to equivalent C declarations for the target architecture, adds the needed FLUSH statements, and writes out an equivalent C file. That C file is compiled as part of package runtime. Native Client's x86-64 support introduces the most complex alignment rules yet, breaking many functions that could until now be portably written in C. Using goc2c for those avoids the breakage. Separately, Keith's work on emitting stack information from the C compiler would require the hand-written functions to add #pragmas specifying how many arguments are result parameters. Using goc2c for those avoids maintaining #pragmas. For both reasons, use goc2c for as many Go-called C functions as possible. This CL is a replay of the bulk of CL 15400047 and CL 15790043, both of which were reviewed as part of the NaCl port and are checked in to the NaCl branch. This CL is part of bringing the NaCl code into the main tree. No new code here, just reformatting and occasional movement into .h files. LGTM=r R=dave, alex.brainman, r CC=golang-codereviews https://golang.org/cl/65220044
2014-02-13runtime: introduce MSpan.needzero instead of writing to span dataRuss Cox
This cleans up the code significantly, and it avoids any possible problems with madvise zeroing out some but not all of the data. Fixes #6400. LGTM=dave R=dvyukov, dave CC=golang-codereviews https://golang.org/cl/57680046
2014-02-12runtime: more precise mprof samplingDmitriy Vyukov
Better sampling of objects that are close in size to sampling rate. See the comment for details. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/43830043
2014-02-12runtime: concurrent GC sweepDmitriy Vyukov
Moves sweep phase out of stoptheworld by adding background sweeper goroutine and lazy on-demand sweeping. It turned out to be somewhat trickier than I expected, because there is no point in time when we know size of live heap nor consistent number of mallocs and frees. So everything related to next_gc, mprof, memstats, etc becomes trickier. At the end of GC next_gc is conservatively set to heap_alloc*GOGC, which is much larger than real value. But after every sweep next_gc is decremented by freed*GOGC. So when everything is swept next_gc becomes what it should be. For mprof I had to introduce 3-generation scheme (allocs, revent_allocs, prev_allocs), because by the end of GC we know number of frees for the *previous* GC. Significant caution is required to not cross yet-unknown real value of next_gc. This is achieved by 2 means: 1. Whenever I allocate a span from MCentral, I sweep a span in that MCentral. 2. Whenever I allocate N pages from MHeap, I sweep until at least N pages are returned to heap. This provides quite strong guarantees that heap does not grow when it should now. http-1 allocated 7036 7033 -0.04% allocs 60 60 +0.00% cputime 51050 46700 -8.52% gc-pause-one 34060569 1777993 -94.78% gc-pause-total 2554 133 -94.79% latency-50 178448 170926 -4.22% latency-95 284350 198294 -30.26% latency-99 345191 220652 -36.08% rss 101564416 101007360 -0.55% sys-gc 6606832 6541296 -0.99% sys-heap 88801280 87752704 -1.18% sys-other 7334208 7405928 +0.98% sys-stack 524288 524288 +0.00% sys-total 103266608 102224216 -1.01% time 50339 46533 -7.56% virtual-mem 292990976 293728256 +0.25% garbage-1 allocated 2983818 2990889 +0.24% allocs 62880 62902 +0.03% cputime 16480000 16190000 -1.76% gc-pause-one 828462467 487875135 -41.11% gc-pause-total 4142312 2439375 -41.11% rss 1151709184 1153712128 +0.17% sys-gc 66068352 66068352 +0.00% sys-heap 1039728640 1039728640 +0.00% sys-other 37776064 40770176 +7.93% sys-stack 8781824 8781824 +0.00% sys-total 1152354880 1155348992 +0.26% time 16496998 16199876 -1.80% virtual-mem 1409564672 1402281984 -0.52% LGTM=rsc R=golang-codereviews, sameer, rsc, iant, jeremyjackins, gobot CC=golang-codereviews, khr https://golang.org/cl/46430043
2014-01-30runtime: increase page size to 8KDmitriy Vyukov
Tcmalloc uses 8K, 32K and 64K pages, and in custom setups 256K pages. Only Chromium uses 4K pages today (in "slow but small" configuration). The general tendency is to increase page size, because it reduces metadata size and DTLB pressure. This change reduces GC pause by ~10% and slightly improves other metrics. json-1 allocated 8037492 8038689 +0.01% allocs 105762 105573 -0.18% cputime 158400000 155800000 -1.64% gc-pause-one 4412234 4135702 -6.27% gc-pause-total 2647340 2398707 -9.39% rss 54923264 54525952 -0.72% sys-gc 3952624 3928048 -0.62% sys-heap 46399488 46006272 -0.85% sys-other 5597504 5290304 -5.49% sys-stack 393216 393216 +0.00% sys-total 56342832 55617840 -1.29% time 158478890 156046916 -1.53% virtual-mem 256548864 256593920 +0.02% garbage-1 allocated 2991113 2986259 -0.16% allocs 62844 62652 -0.31% cputime 16330000 15860000 -2.88% gc-pause-one 789108229 725555211 -8.05% gc-pause-total 3945541 3627776 -8.05% rss 1143660544 1132253184 -1.00% sys-gc 65609600 65806208 +0.30% sys-heap 1032388608 1035599872 +0.31% sys-other 37501632 22777664 -39.26% sys-stack 8650752 8781824 +1.52% sys-total 1144150592 1132965568 -0.98% time 16364602 15891994 -2.89% virtual-mem 1327296512 1313746944 -1.02% This is the exact reincarnation of already LGTMed: https://golang.org/cl/45770044 which must not break darwin/freebsd after: https://golang.org/cl/56630043 TBR=iant LGTM=khr, iant R=iant, khr CC=golang-codereviews https://golang.org/cl/58230043
2014-01-29runtime: prepare for 8K pagesDmitriy Vyukov
Ensure than heap is PageSize aligned. LGTM=iant R=iant, dave, gobot CC=golang-codereviews https://golang.org/cl/56630043
2014-01-28runtime: prefetch next block in mallocgcDmitriy Vyukov
json-1 cputime 99600000 98600000 -1.00% time 100005493 98859693 -1.15% garbage-1 cputime 15760000 15440000 -2.03% time 15791759 15471701 -2.03% LGTM=khr R=golang-codereviews, gobot, khr, dave CC=bradfitz, golang-codereviews, iant https://golang.org/cl/57310043
2014-01-28runtime: adjust malloc race instrumentation for tiny allocsDmitriy Vyukov
Tiny alloc memory block is shared by different goroutines running on the same thread. We call racemalloc after enabling preemption in mallocgc, as the result another goroutine can act on not yet race-cleared tiny block. Call racemalloc before enabling preemption. Fixes #7224. LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/57730043
2014-01-28runtime: fix windows buildDmitriy Vyukov
Currently windows crashes because early allocs in schedinit try to allocate tiny memory blocks, but m->p is not yet setup. I've considered calling procresize(1) earlier in schedinit, but this refactoring is better and must fix the issue as well. Fixes #7218. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/54570045
2014-01-27runtime: fix buffer overflow in stringtosliceruneDmitriy Vyukov
On 32-bits n*sizeof(r[0]) can overflow. Or it can become 1<<32-eps, and mallocgc will "successfully" allocate 0 pages for it, there are no checks downstream and MHeap_Grow just does: npage = (npage+15)&~15; ask = npage<<PageShift; LGTM=khr R=golang-codereviews, khr CC=golang-codereviews https://golang.org/cl/54760045
2014-01-24runtime: combine small NoScan allocationsDmitriy Vyukov
Combine NoScan allocations < 16 bytes into a single memory block. Reduces number of allocations on json/garbage benchmarks by 10+%. json-1 allocated 8039872 7949194 -1.13% allocs 105774 93776 -11.34% cputime 156200000 100700000 -35.53% gc-pause-one 4908873 3814853 -22.29% gc-pause-total 2748969 2899288 +5.47% rss 52674560 43560960 -17.30% sys-gc 3796976 3256304 -14.24% sys-heap 43843584 35192832 -19.73% sys-other 5589312 5310784 -4.98% sys-stack 393216 393216 +0.00% sys-total 53623088 44153136 -17.66% time 156193436 100886714 -35.41% virtual-mem 256548864 256540672 -0.00% garbage-1 allocated 2996885 2932982 -2.13% allocs 62904 55200 -12.25% cputime 17470000 17400000 -0.40% gc-pause-one 932757485 925806143 -0.75% gc-pause-total 4663787 4629030 -0.75% rss 1151074304 1133670400 -1.51% sys-gc 66068352 65085312 -1.49% sys-heap 1039728640 1024065536 -1.51% sys-other 38038208 37485248 -1.45% sys-stack 8650752 8781824 +1.52% sys-total 1152485952 1135417920 -1.48% time 17478088 17418005 -0.34% virtual-mem 1343709184 1324204032 -1.45% LGTM=iant, bradfitz R=golang-codereviews, dave, iant, rsc, bradfitz CC=golang-codereviews, khr https://golang.org/cl/38750047
2014-01-23undo CL 45770044 / d795425bfa18Dmitriy Vyukov
Breaks darwin and freebsd. ««« original CL description runtime: increase page size to 8K Tcmalloc uses 8K, 32K and 64K pages, and in custom setups 256K pages. Only Chromium uses 4K pages today (in "slow but small" configuration). The general tendency is to increase page size, because it reduces metadata size and DTLB pressure. This change reduces GC pause by ~10% and slightly improves other metrics. json-1 allocated 8037492 8038689 +0.01% allocs 105762 105573 -0.18% cputime 158400000 155800000 -1.64% gc-pause-one 4412234 4135702 -6.27% gc-pause-total 2647340 2398707 -9.39% rss 54923264 54525952 -0.72% sys-gc 3952624 3928048 -0.62% sys-heap 46399488 46006272 -0.85% sys-other 5597504 5290304 -5.49% sys-stack 393216 393216 +0.00% sys-total 56342832 55617840 -1.29% time 158478890 156046916 -1.53% virtual-mem 256548864 256593920 +0.02% garbage-1 allocated 2991113 2986259 -0.16% allocs 62844 62652 -0.31% cputime 16330000 15860000 -2.88% gc-pause-one 789108229 725555211 -8.05% gc-pause-total 3945541 3627776 -8.05% rss 1143660544 1132253184 -1.00% sys-gc 65609600 65806208 +0.30% sys-heap 1032388608 1035599872 +0.31% sys-other 37501632 22777664 -39.26% sys-stack 8650752 8781824 +1.52% sys-total 1144150592 1132965568 -0.98% time 16364602 15891994 -2.89% virtual-mem 1327296512 1313746944 -1.02% R=golang-codereviews, dave, khr, rsc, khr CC=golang-codereviews https://golang.org/cl/45770044 »»» R=golang-codereviews CC=golang-codereviews https://golang.org/cl/56060043
2014-01-23runtime: increase page size to 8KDmitriy Vyukov
Tcmalloc uses 8K, 32K and 64K pages, and in custom setups 256K pages. Only Chromium uses 4K pages today (in "slow but small" configuration). The general tendency is to increase page size, because it reduces metadata size and DTLB pressure. This change reduces GC pause by ~10% and slightly improves other metrics. json-1 allocated 8037492 8038689 +0.01% allocs 105762 105573 -0.18% cputime 158400000 155800000 -1.64% gc-pause-one 4412234 4135702 -6.27% gc-pause-total 2647340 2398707 -9.39% rss 54923264 54525952 -0.72% sys-gc 3952624 3928048 -0.62% sys-heap 46399488 46006272 -0.85% sys-other 5597504 5290304 -5.49% sys-stack 393216 393216 +0.00% sys-total 56342832 55617840 -1.29% time 158478890 156046916 -1.53% virtual-mem 256548864 256593920 +0.02% garbage-1 allocated 2991113 2986259 -0.16% allocs 62844 62652 -0.31% cputime 16330000 15860000 -2.88% gc-pause-one 789108229 725555211 -8.05% gc-pause-total 3945541 3627776 -8.05% rss 1143660544 1132253184 -1.00% sys-gc 65609600 65806208 +0.30% sys-heap 1032388608 1035599872 +0.31% sys-other 37501632 22777664 -39.26% sys-stack 8650752 8781824 +1.52% sys-total 1144150592 1132965568 -0.98% time 16364602 15891994 -2.89% virtual-mem 1327296512 1313746944 -1.02% R=golang-codereviews, dave, khr, rsc, khr CC=golang-codereviews https://golang.org/cl/45770044
2014-01-21runtime: zero 2-word memory blocks in-placeDmitriy Vyukov
Currently for 2-word blocks we set the flag to clear the flag. Makes no sense. In particular on 32-bits we call memclr always. R=golang-codereviews, dave, iant CC=golang-codereviews, khr, rsc https://golang.org/cl/41170044
2014-01-09runtime: fix 32-bit malloc for pointers >= 0x80000000Ian Lance Taylor
The spans array is allocated in runtime·mallocinit. On a 32-bit system the number of entries in the spans array is MaxArena32 / PageSize, which (2U << 30) / (1 << 12) == (1 << 19). So we are allocating an array that can hold 19 bits for an index that can hold 20 bits. According to the comment in the function, this is intentional: we only allocate enough spans (and bitmaps) for a 2G arena, because allocating more would probably be wasteful. But since the span index is simply the upper 20 bits of the memory address, this scheme only works if memory addresses are limited to the low 2G of memory. That would be OK if we were careful to enforce it, but we're not. What we are careful to enforce, in functions like runtime·MHeap_SysAlloc, is that we always return addresses between the heap's arena_start and arena_start + MaxArena32. We generally get away with it because we start allocating just after the program end, so we only run into trouble with programs that allocate a lot of memory, enough to get past address 0x80000000. This changes the code that computes a span index to subtract arena_start on 32-bit systems just as we currently do on 64-bit systems. R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/49460043
2014-01-08runtime: deallocate specials before deallocating the underlying object.Keith Randall
R=dvyukov CC=golang-codereviews https://golang.org/cl/48840043
2014-01-07runtime: use special records hung off the MSpan toKeith Randall
record finalizers and heap profile info. Enables removing the special bit from the heap bitmap. Also provides a generic mechanism for annotating occasional heap objects. finalizers overhead per obj old 680 B 80 B avg new 16 B/span 48 B profile overhead per obj old 32KB 24 B + hash tables new 16 B/span 24 B R=cshapiro, khr, dvyukov, gobot CC=golang-codereviews https://golang.org/cl/13314053
2013-12-18runtime: mark objects in free lists as allocated and unscannable.Keith Randall
On the plus side, we don't need to change the bits when mallocing pointerless objects. On the other hand, we need to mark objects in the free lists during GC. But the free lists are small at GC time, so it should be a net win. benchmark old ns/op new ns/op delta BenchmarkMalloc8 40 33 -17.65% BenchmarkMalloc16 45 38 -15.72% BenchmarkMallocTypeInfo8 58 59 +0.85% BenchmarkMallocTypeInfo16 63 64 +1.10% R=golang-dev, rsc, dvyukov CC=cshapiro, golang-dev https://golang.org/cl/41040043
2013-12-17runtime: don't crash in SetFinalizer if sizeof *x is zeroBrad Fitzpatrick
And document it explicitly, even though it already said it wasn't guaranteed. Fixes #6857 R=golang-dev, khr CC=golang-dev https://golang.org/cl/43580043
2013-12-06runtime: add GODEBUG option for an electric fence like heap modeCarl Shapiro
When enabled this new debugging mode will allocate objects on their own page and never recycle memory addresses. This is an essential tool to root cause a broad class of heap corruption. R=golang-dev, dave, daniel.morsing, dvyukov, rsc, iant, cshapiro CC=golang-dev https://golang.org/cl/22060046
2013-12-03runtime: add an allocation and free tracing for gc debuggingCarl Shapiro
Output for an allocation and free (sweep) follows MProf_Malloc(p=0xc2100210a0, size=0x50, type=0x0 <single object>) #0 0x46ee15 runtime.mallocgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:141 #1 0x47004f runtime.settype_flush /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:612 #2 0x45f92c gc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2071 #3 0x45f89e mgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2050 #4 0x45258b runtime.mcall /usr/local/google/home/cshapiro/go/src/pkg/runtime/asm_amd64.s:179 MProf_Free(p=0xc2100210a0, size=0x50) #0 0x46ee15 runtime.mallocgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:141 #1 0x47004f runtime.settype_flush /usr/local/google/home/cshapiro/go/src/pkg/runtime/malloc.goc:612 #2 0x45f92c gc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2071 #3 0x45f89e mgc /usr/local/google/home/cshapiro/go/src/pkg/runtime/mgc0.c:2050 #4 0x45258b runtime.mcall /usr/local/google/home/cshapiro/go/src/pkg/runtime/asm_amd64.s:179 R=golang-dev, dvyukov, rsc, cshapiro CC=golang-dev https://golang.org/cl/21990045
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-08-29cmd/cc,runtime: change preprocessor to expand macros inside ofKeith Randall
#pragma textflag and #pragma dataflag directives. Update dataflag directives to use symbols instead of integer constants. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/13310043
2013-08-23runtime: rename FlagNoPointers to FlagNoScan. Better representsKeith Randall
the use of the flag, especially for objects which actually do have pointers but we don't want the GC to scan them. R=golang-dev, cshapiro CC=golang-dev https://golang.org/cl/13181045
2013-08-15runtime: remove old preemption checksDmitriy Vyukov
runtime.gcwaiting checks are not needed anymore R=golang-dev, khr CC=golang-dev https://golang.org/cl/12934043
2013-08-14runtime: make SetFinalizer(x, f) accept any f for which f(x) is validRuss Cox
Originally the requirement was f(x) where f's argument is exactly x's type. CL 11858043 relaxed the requirement in a non-standard way: f's argument must be exactly x's type or interface{}. If we're going to relax the requirement, it should be done in a way consistent with the rest of Go. This CL allows f's argument to have any type for which x is assignable; that's the same requirement the compiler would impose if compiling f(x) directly. Fixes #5368. R=dvyukov, bradfitz, pieter CC=golang-dev https://golang.org/cl/12895043
2013-08-12runtime: change textflags from numbers to symbolsKeith Randall
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/12798043
2013-08-12runtime: remove unused m->racepcDmitriy Vyukov
The original plan was to collect allocation stacks for all memory blocks. But it was never implemented and it's not in near plans and it's unclear how to do it at all. R=golang-dev, dave, bradfitz CC=golang-dev https://golang.org/cl/12724044
2013-08-04runtime: remove dead codeDmitriy Vyukov
Remove dead code related to allocation of type metadata with SysAlloc. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/12311045
2013-07-29runtime: allow SetFinalizer with a func(interface{})Pieter Droogendijk
Fixes #5368. R=golang-dev, dvyukov CC=golang-dev, rsc https://golang.org/cl/11858043
2013-07-26runtime: refactor mallocgcDmitriy Vyukov
Make it accept type, combine flags. Several reasons for the change: 1. mallocgc and settype must be atomic wrt GC 2. settype is called from only one place now 3. it will help performance (eventually settype functionality must be combined with markallocated) 4. flags are easier to read now (no mallocgc(sz, 0, 1, 0) anymore) R=golang-dev, iant, nightlyone, rsc, dave, khr, bradfitz, r CC=golang-dev https://golang.org/cl/10136043
2013-07-19runtime: hide mheap from GCDmitriy Vyukov
It contains pointers to first blocks of lots of spans. R=golang-dev, iant CC=golang-dev https://golang.org/cl/11416046
2013-07-18runtime: disable preemption during runtime.settypeRuss Cox
It assumes that the m will not change, and the m may change if the goroutine is preempted. R=golang-dev, r CC=golang-dev https://golang.org/cl/11560043
2013-07-17runtime: more reliable preemptionDmitriy Vyukov
Currently preemption signal g->stackguard0==StackPreempt can be lost if it is received when preemption is disabled (e.g. m->lock!=0). This change duplicates the preemption signal in g->preempt and restores g->stackguard0 when preemption is enabled. Update #543. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10792043
2013-06-13runtime: fix bug introduced in cl/10256043Dmitriy Vyukov
R=golang-dev, dave CC=golang-dev https://golang.org/cl/10260043
2013-06-13runtime: use ROUND macro for roundingDmitriy Vyukov
R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/10256043
2013-06-12runtime: more flexible heap memory mapping on 64-bitsDmitriy Vyukov
Fixes #5641. R=golang-dev, dave, daniel.morsing, iant CC=golang-dev, kcc https://golang.org/cl/10126044
2013-06-12runtime: round spans_size up to page boundaryShenghou Ma
in case we have weird (not page aligned) memory limit. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10199043
2013-06-10runtime: use persistentalloc instead of SysAlloc in FixAllocDmitriy Vyukov
Also reduce FixAlloc allocation granulatiry from 128k to 16k, small programs do not need that much memory for MCache's and MSpan's. R=golang-dev, khr CC=golang-dev https://golang.org/cl/10140044
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 22:57:47 +0000