aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime
AgeCommit message (Collapse)Author
2014-05-20reflect: don't panic on delete from nil map.Keith Randall
Fixes #8051 LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/95560046
2014-05-20all: fix "the the" typos.Shenghou Ma
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/93470043
2014-05-20runtime: revise the document of Version()Shenghou Ma
Fixes #7701. (again, differently) LGTM=rsc R=iant, rsc CC=golang-codereviews https://golang.org/cl/94560043
2014-05-20build: make nacl passRuss Cox
Add nacl.bash, the NaCl version of all.bash. It's a separate script because it builds a variant of package syscall with a large zip file embedded in it, containing all the input files needed for tests. Disable various tests new since the last round, mostly the ones using os/exec. Fixes #7945. LGTM=dave R=golang-codereviews, remyoudompheng, dave, bradfitz CC=golang-codereviews https://golang.org/cl/100590044
2014-05-20runtime: switch default stack size back to 8kBRuss Cox
The move from 4kB to 8kB in Go 1.2 was to eliminate many stack split hot spots. The move back to 4kB was predicated on copying stacks eliminating the potential for hot spots. Unfortunately, the fact that stacks do not copy 100% of the time means that hot spots can still happen under the right conditions, and the slowdown is worse now than it was in Go 1.2. There is a real program in issue 8030 that sees about a 30x slowdown: it has a reflect call near the top of the stack which inhibits any stack copying on that segment. Go back to 8kB until stack copying can be used 100% of the time. Fixes #8030. LGTM=khr, dave, iant R=iant, khr, r, bradfitz, dave CC=golang-codereviews https://golang.org/cl/92540043
2014-05-19reflect: test, fix access to nil mapsRuss Cox
Fixes #8010. LGTM=bradfitz, khr R=khr, bradfitz, dvyukov CC=golang-codereviews https://golang.org/cl/91450048
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-05-15runtime: make scan of pointer-in-interface same as scan of pointerRuss Cox
The GC program describing a data structure sometimes trusts the pointer base type and other times does not (if not, the garbage collector must fall back on per-allocation type information stored in the heap). Make the scanning of a pointer in an interface do the same. This fixes a crash in a particular use of reflect.SliceHeader. Fixes #8004. LGTM=khr R=golang-codereviews, khr CC=0xe2.0x9a.0x9b, golang-codereviews, iant, r https://golang.org/cl/100470045
2014-05-13runtime: fix triggering of forced GCDmitriy Vyukov
mstats.last_gc is unix time now, it is compared with abstract monotonic time. On my machine GC is forced every 5 mins regardless of last_gc. LGTM=rsc R=golang-codereviews CC=golang-codereviews, iant, rsc https://golang.org/cl/91350045
2014-05-13runtime: handle decommit failure gracefully on WindowsRuss Cox
I have no test case for this at tip. The original report included a program crashing at revision 88ac7297d2fa. I tested this code at that revision and it does fix the crash. However, at tip the reported code no longer crashes, presumably because some allocation patterns have changed. I believe the bug is still present at tip and that this code still fixes it. Fixes #7143. LGTM=alex.brainman R=golang-codereviews, alex.brainman CC=dvyukov, golang-codereviews https://golang.org/cl/96300046
2014-05-12runtime: add copy of math.sqrt for use by arm softfloatRuss Cox
If it's not used (such as on other systems or if softfloat is disabled) the linker will discard it. The alternative is to teach cmd/go that every binary depends on math implicitly on arm. I started down that path but it's too scary. If we're going to get dependencies right we should get dependencies right. Fixes #6994. LGTM=bradfitz, dave R=golang-codereviews, bradfitz, dave CC=golang-codereviews https://golang.org/cl/95290043
2014-05-09undo CL 100330043 / e4248ed0037cBrad Fitzpatrick
<enter reason for undo> ««« original CL description runtime/race: fix the link for the race detector. LGTM=bradfitz R=golang-dev, bradfitz CC=golang-codereviews https://golang.org/cl/100330043 »»» TBR=minux R=minux.ma CC=golang-codereviews https://golang.org/cl/96200044
2014-05-09runtime/race: fix the link for the race detector.Bill Neubauer
LGTM=bradfitz R=golang-dev, bradfitz CC=golang-codereviews https://golang.org/cl/100330043
2014-05-09runtime: be a lot more lenient on smhasher avalanche test.Keith Randall
Fixes #7943 LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/98170043
2014-05-08runtime: write memory profile statistics to the heap dump.Keith Randall
LGTM=rsc R=rsc, khr CC=golang-codereviews https://golang.org/cl/97010043
2014-05-07runtime: use duff zero and copy to initialize memoryKeith Randall
benchmark old ns/op new ns/op delta BenchmarkCopyFat512 1307 329 -74.83% BenchmarkCopyFat256 666 169 -74.62% BenchmarkCopyFat1024 2617 671 -74.36% BenchmarkCopyFat128 343 89.0 -74.05% BenchmarkCopyFat64 182 48.9 -73.13% BenchmarkCopyFat32 103 28.8 -72.04% BenchmarkClearFat128 102 46.6 -54.31% BenchmarkClearFat512 344 167 -51.45% BenchmarkClearFat64 50.5 26.5 -47.52% BenchmarkClearFat256 147 87.2 -40.68% BenchmarkClearFat32 22.7 16.4 -27.75% BenchmarkClearFat1024 511 662 +29.55% Fixes #7624 LGTM=rsc R=golang-codereviews, khr, bradfitz, josharian, dave, rsc CC=golang-codereviews https://golang.org/cl/92760044
2014-05-07runtime: optimize markspanDmitriy Vyukov
Increases throughput by 2x on a memory hungry program on 8-node NUMA machine. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/100230043
2014-05-07runtime: fix bug in cpu profilerDmitriy Vyukov
Number of lost samples was overcounted (never reset). Also remove unused variable (it's trivial to restore it for debugging if needed). LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, rsc https://golang.org/cl/96060043
2014-05-02std lib: fix various typos in commentsRobert Griesemer
Where the spelling changed from British to US norm (e.g., optimise -> optimize) it follows the style in that file. LGTM=adonovan R=golang-codereviews, adonovan CC=golang-codereviews https://golang.org/cl/96980043
2014-05-02runtime: fix bug in GOTRACEBACK=crash causing suppression of core dumps.Alan Donovan
Because gotraceback is called early and often, its cache commits to the value of getenv("GOTRACEBACK") before getenv is even ready. So now we reset its cache once getenv becomes ready. Panicking programs now dump core again. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/97800045
2014-05-02runtime: do not set m->locks around memory allocationDmitriy Vyukov
If slice append is the only place where a program allocates, then it will consume all available memory w/o triggering GC. This was demonstrated in the issue. Fixes #7922. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews, iant, khr https://golang.org/cl/91010048
2014-05-02runtime: make MemStats.LastGC Unix time againDmitriy Vyukov
The monotonic clock patch changed all runtime times to abstract monotonic time. As the result user-visible MemStats.LastGC become monotonic time as well. Restore Unix time for LastGC. This is the simplest way to expose time.now to runtime that I found. Another option would be to change time.now to C called int64 runtime.unixnanotime() and then express time.now in terms of it. But this would require to introduce 2 64-bit divisions into time.now. Another option would be to change time.now to C called void runtime.unixnanotime1(struct {int64 sec, int32 nsec} *now) and then express both time.now and runtime.unixnanotime in terms of it. Fixes #7852. LGTM=minux.ma, iant R=minux.ma, rsc, iant CC=golang-codereviews https://golang.org/cl/93720045
2014-05-01runtime: correctly type interface data.Keith Randall
The backing memory for >1 word interfaces was being scanned conservatively. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/94000043
2014-04-28runtime: clean up scanning of GsKeith Randall
Use a real type for Gs instead of scanning them conservatively. Zero the schedlink pointer when it is dead. Update #7820 LGTM=rsc R=rsc, dvyukov CC=golang-codereviews https://golang.org/cl/89360043
2014-04-28runtime: heapdump - make sure spans are swept before dumping.Keith Randall
LGTM=rsc R=golang-codereviews, adonovan, rsc CC=golang-codereviews https://golang.org/cl/90440043
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-21runtime/race: add test for issue 7561.Rémy Oudompheng
LGTM=dvyukov R=rsc, iant, khr, dvyukov CC=golang-codereviews https://golang.org/cl/76520045
2014-04-21runtime, go/build: re-enable cgo on FreeBSD.Shenghou Ma
Fixes #7331. LGTM=dave, iant R=golang-codereviews, dave, gobot, iant CC=golang-codereviews https://golang.org/cl/89150043
2014-04-21runtime, cmd/ld, cmd/5l, run.bash: enable external linking on FreeBSD/ARM.Shenghou Ma
Update #7331 LGTM=dave, iant R=golang-codereviews, dave, gobot, iant CC=golang-codereviews https://golang.org/cl/89520043
2014-04-19cmd/nm: print symbol sizes for windows pe executablesAlex Brainman
Fixes #6973 LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/88820043
2014-04-16runtime: crash when func main calls Goexit and all other goroutines exitRuss Cox
This has typically crashed in the past, although usually with an 'all goroutines are asleep - deadlock!' message that shows no goroutines (because there aren't any). Previous discussion at: https://groups.google.com/d/msg/golang-nuts/uCT_7WxxopQ/BoSBlLFzUTkJ https://groups.google.com/d/msg/golang-dev/KUojayEr20I/u4fp_Ej5PdUJ http://golang.org/issue/7711 There is general agreement that runtime.Goexit terminates the main goroutine, so that main cannot return, so the program does not exit. The interpretation that all other goroutines exiting causes an exit(0) is relatively new and was not part of those discussions. That is what this CL changes. Thankfully, even though the exit(0) has been there for a while, some other accounting bugs made it very difficult to trigger, so it is reasonable to replace. In particular, see golang.org/issue/7711#c10 for an examination of the behavior across past releases. Fixes #7711. LGTM=iant, r R=golang-codereviews, iant, dvyukov, r CC=golang-codereviews https://golang.org/cl/88210044
2014-04-16runtime: adjust GC debug print to include source pointersRuss Cox
Having the pointers means you can grub around in the binary finding out more about them. This helped with issue 7748. LGTM=minux.ma, bradfitz R=golang-codereviews, minux.ma, bradfitz CC=golang-codereviews https://golang.org/cl/88090045
2014-04-15liblink: introduce TLS register on 386 and amd64Russ Cox
When I did the original 386 ports on Linux and OS X, I chose to define GS-relative expressions like 4(GS) as relative to the actual thread-local storage base, which was usually GS but might not be (it might be FS, or it might be a different constant offset from GS or FS). The original scope was limited but since then the rewrites have gotten out of control. Sometimes GS is rewritten, sometimes FS. Some ports do other rewrites to enable shared libraries and other linking. At no point in the code is it clear whether you are looking at the real GS/FS or some synthesized thing that will be rewritten. The code manipulating all these is duplicated in many places. The first step to fixing issue 7719 is to make the code intelligible again. This CL adds an explicit TLS pseudo-register to the 386 and amd64. As a register, TLS refers to the thread-local storage base, and it can only be loaded into another register: MOVQ TLS, AX An offset from the thread-local storage base is written off(reg)(TLS*1). Semantically it is off(reg), but the (TLS*1) annotation marks this as indexing from the loaded TLS base. This emits a relocation so that if the linker needs to adjust the offset, it can. For example: MOVQ TLS, AX MOVQ 8(AX)(TLS*1), CX // load m into CX On systems that support direct access to the TLS memory, this pair of instructions can be reduced to a direct TLS memory reference: MOVQ 8(TLS), CX // load m into CX The 2-instruction and 1-instruction forms correspond roughly to ELF TLS initial exec mode and ELF TLS local exec mode, respectively. Liblink applies this rewrite on systems that support the 1-instruction form. The decision is made using only the operating system (and probably the -shared flag, eventually), not the link mode. If some link modes on a particular operating system require the 2-instruction form, then all builds for that operating system will use the 2-instruction form, so that the link mode decision can be delayed to link time. Obviously it is late to be making changes like this, but I despair of correcting issue 7719 and issue 7164 without it. To make sure I am not changing existing behavior, I built a "hello world" program for every GOOS/GOARCH combination we have and then worked to make sure that the rewrite generates exactly the same binaries, byte for byte. There are a handful of TODOs in the code marking kludges to get the byte-for-byte property, but at least now I can explain exactly how each binary is handled. The targets I tested this way are: darwin-386 darwin-amd64 dragonfly-386 dragonfly-amd64 freebsd-386 freebsd-amd64 freebsd-arm linux-386 linux-amd64 linux-arm nacl-386 nacl-amd64p32 netbsd-386 netbsd-amd64 openbsd-386 openbsd-amd64 plan9-386 plan9-amd64 solaris-amd64 windows-386 windows-amd64 There were four exceptions to the byte-for-byte goal: windows-386 and windows-amd64 have a time stamp at bytes 137 and 138 of the header. darwin-386 and plan9-386 have five or six modified bytes in the middle of the Go symbol table, caused by editing comments in runtime/sys_{darwin,plan9}_386.s. Fixes #7164. LGTM=iant R=iant, aram, minux.ma, dave CC=golang-codereviews https://golang.org/cl/87920043
2014-04-15runtime: fix program termination when main goroutine calls GoexitDmitriy Vyukov
Do not consider idle finalizer/bgsweep/timer goroutines as doing something useful. We can't simply set isbackground for the whole lifetime of the goroutines, because when finalizer goroutine calls user function, we do want to consider it as doing something useful. This is borken due to timers for quite some time. With background sweep is become even more broken. Fixes #7784. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/87960044
2014-04-14sync: less agressive local caching in PoolDmitriy Vyukov
Currently Pool can cache up to 15 elements per P, and these elements are not accesible to other Ps. If a Pool caches large objects, say 2MB, and GOMAXPROCS is set to a large value, say 32, then the Pool can waste up to 960MB. The new caching policy caches at most 1 per-P element, the rest is shared between Ps. Get/Put performance is unchanged. Nested Get/Put performance is 57% worse. However, overall scalability of nested Get/Put is significantly improved, so the new policy starts winning under contention. benchmark old ns/op new ns/op delta BenchmarkPool 27.4 26.7 -2.55% BenchmarkPool-4 6.63 6.59 -0.60% BenchmarkPool-16 1.98 1.87 -5.56% BenchmarkPool-64 1.93 1.86 -3.63% BenchmarkPoolOverlflow 3970 6235 +57.05% BenchmarkPoolOverlflow-4 10935 1668 -84.75% BenchmarkPoolOverlflow-16 13419 520 -96.12% BenchmarkPoolOverlflow-64 10295 380 -96.31% LGTM=rsc R=rsc CC=golang-codereviews, khr https://golang.org/cl/86020043
2014-04-13runtime: increase timeout in TestStackGrowthRuss Cox
It looks like maybe on slower builders 4 seconds is not enough. Trying to get rid of the flaky failures. TBR=iant CC=golang-codereviews https://golang.org/cl/86870044
2014-04-11runtime: make stack growth test shorterRuss Cox
It runs too long in -short mode. Disable the one in init, because it doesn't respect -short. Make the part that claims to test execution in a finalizer actually execute the test in the finalizer. LGTM=bradfitz R=golang-codereviews, bradfitz CC=aram.h, golang-codereviews, iant, khr https://golang.org/cl/86550045
2014-04-10runtime: make times in GODEBUG=gctrace=1 output clearerRuss Cox
TBR=0intro CC=golang-codereviews https://golang.org/cl/86620043
2014-04-10runtime: no longer skip stack growth test in short modeDavid du Colombier
We originally decided to skip this test in short mode to prevent the parallel runtime test to timeout on the Plan 9 builder. This should no longer be required since the issue was fixed in CL 86210043. LGTM=dave, bradfitz R=dvyukov, dave, bradfitz CC=golang-codereviews, rsc https://golang.org/cl/84790044
2014-04-10runtime: fix semasleep on Plan 9David du Colombier
If you pass ns = 100,000 to this function, timediv will return ms = 0. tsemacquire in /sys/src/9/port/sysproc.c will return immediately when ms == 0 and the semaphore cannot be acquired immediately - it doesn't sleep - so notetsleep will spin, chewing cpu and repeatedly reading the time, until the 100us have passed. Thanks to the time reads it won't take too many iterations, but whatever we are waiting for does not get a chance to run. Eventually the notetsleep spin loop returns and we end up in the stoptheworld spin loop - actually a sleep loop but we're not doing a good job of sleeping. After 100ms or so of this, the kernel says enough and schedules a different thread. That thread manages to do whatever we're waiting for, and the spinning in the other thread stops. If tsemacquire had actually slept, this would have happened much quicker. Many thanks to Russ Cox for help debugging. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/86210043
2014-04-09runtime: use 3x fewer nanotime calls in garbage collectionRuss Cox
Cuts the number of calls from 6 to 2 in the non-debug case. LGTM=iant R=golang-codereviews, iant CC=0intro, aram, golang-codereviews, khr https://golang.org/cl/86040043
2014-04-09runtime: fix flaky linux/386 buildRuss Cox
TBR=iant CC=golang-codereviews https://golang.org/cl/86030043
2014-04-09runtime: fix GOTRACEBACK on Plan 9David du Colombier
Getenv() should not call malloc when called from gotraceback(). Instead, we return a static buffer in this case, with enough room to hold the longest value. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/85680043
2014-04-08runtime: cache gotraceback settingRuss Cox
On Plan 9 gotraceback calls getenv calls malloc, and we gotraceback on every call to gentraceback, which happens during garbage collection. Honestly I don't even know how this works on Plan 9. I suspect it does not, and that we are getting by because no one has tried to run with $GOTRACEBACK set at all. This will speed up all the other systems by epsilon, since they won't call getenv and atoi repeatedly. LGTM=bradfitz R=golang-codereviews, bradfitz, 0intro CC=golang-codereviews https://golang.org/cl/85430046
2014-04-08reflect, runtime: fix crash in GC due to reflect.call + precise GCRuss Cox
Given type Outer struct { *Inner ... } the compiler generates the implementation of (*Outer).M dispatching to the embedded Inner. The implementation is logically: func (p *Outer) M() { (p.Inner).M() } but since the only change here is the replacement of one pointer receiver with another, the actual generated code overwrites the original receiver with the p.Inner pointer and then jumps to the M method expecting the *Inner receiver. During reflect.Value.Call, we create an argument frame and the associated data structures to describe it to the garbage collector, populate the frame, call reflect.call to run a function call using that frame, and then copy the results back out of the frame. The reflect.call function does a memmove of the frame structure onto the stack (to set up the inputs), runs the call, and the memmoves the stack back to the frame structure (to preserve the outputs). Originally reflect.call did not distinguish inputs from outputs: both memmoves were for the full stack frame. However, in the case where the called function was one of these wrappers, the rewritten receiver is almost certainly a different type than the original receiver. This is not a problem on the stack, where we use the program counter to determine the type information and understand that during (*Outer).M the receiver is an *Outer while during (*Inner).M the receiver in the same memory word is now an *Inner. But in the statically typed argument frame created by reflect, the receiver is always an *Outer. Copying the modified receiver pointer off the stack into the frame will store an *Inner there, and then if a garbage collection happens to scan that argument frame before it is discarded, it will scan the *Inner memory as if it were an *Outer. If the two have different memory layouts, the collection will intepret the memory incorrectly. Fix by only copying back the results. Fixes #7725. LGTM=khr R=khr CC=dave, golang-codereviews https://golang.org/cl/85180043
2014-04-08runtime/race: more precise handling of channel synchronizationDmitriy Vyukov
It turns out there is a relatively common pattern that relies on inverted channel semaphore: gate := make(chan bool, N) for ... { // limit concurrency gate <- true go func() { foo(...) <-gate }() } // join all goroutines for i := 0; i < N; i++ { gate <- true } So handle synchronization on inverted semaphores with cap>1. Fixes #7718. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/84880046
2014-04-07runtime: make sure associated defers are copyable before trying to copy a stack.Keith Randall
Defers generated from cgo lie to us about their argument layout. Mark those defers as not copyable. CL 83820043 contains an additional test for this code and should be checked in (and enabled) after this change is in. Fixes bug 7695. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/84740043
2014-04-07runtime: fix heapdump bugs.Keith Randall
Iterate the right number of times in arrays and channels. Handle channels with zero-sized objects in them. Output longer type names if we have them. Compute argument offset correctly. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/82980043
2014-04-04runtime: fix plan9 warning.Keith Randall
I have no idea what this code is for, but it pretty clearly needs to be uint64, not uint32. LGTM=aram R=0intro, aram CC=golang-codereviews https://golang.org/cl/84410043
2014-04-03cmd/gc, runtime: make GODEBUG=gcdead=1 mode work with livenessRuss Cox
Trying to make GODEBUG=gcdead=1 work with liveness and in particular ambiguously live variables. 1. In the liveness computation, mark all ambiguously live variables as live for the entire function, except the entry. They are zeroed directly after entry, and we need them not to be poisoned thereafter. 2. In the liveness computation, compute liveness (and deadness) for all parameters, not just pointer-containing parameters. Otherwise gcdead poisons untracked scalar parameters and results. 3. Fix liveness debugging print for -live=2 to use correct bitmaps. (Was not updated for compaction during compaction CL.) 4. Correct varkill during map literal initialization. Was killing the map itself instead of the inserted value temp. 5. Disable aggressive varkill cleanup for call arguments if the call appears in a defer or go statement. 6. In the garbage collector, avoid bug scanning empty strings. An empty string is two zeros. The multiword code only looked at the first zero and then interpreted the next two bits in the bitmap as an ordinary word bitmap. For a string the bits are 11 00, so if a live string was zero length with a 0 base pointer, the poisoning code treated the length as an ordinary word with code 00, meaning it needed poisoning, turning the string into a poison-length string with base pointer 0. By the same logic I believe that a live nil slice (bits 11 01 00) will have its cap poisoned. Always scan full multiword struct. 7. In the runtime, treat both poison words (PoisonGC and PoisonStack) as invalid pointers that warrant crashes. Manual testing as follows: - Create a script called gcdead on your PATH containing: #!/bin/bash GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@" - Now you can build a test and then run 'gcdead ./foo.test'. - More importantly, you can run 'go test -short -exec gcdead std' to run all the tests. Fixes #7676. While here, enable the precise scanning of slices, since that was disabled due to bugs like these. That now works, both with and without gcdead. Fixes #7549. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83410044
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 19:45:52 +0000