aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime
AgeCommit message (Collapse)Author
2011-07-11[release-branch.r58] runtime/cgo: fix for OS X 10.7Russ Cox
««« CL 4603057 / 0905a2ca94c6 runtime/cgo: fix for OS X 10.7 Correct a few error messages (libcgo -> runtime/cgo) and delete old nacl_386.c file too. Fixes #1657. R=iant CC=golang-dev https://golang.org/cl/4603057 »»» R=adg CC=golang-dev https://golang.org/cl/4698041
2011-06-095l: fix softfloat nitsRuss Cox
Need to load math.a so that sqrtGoC is available. Also was missing prototype. R=ken2 CC=golang-dev https://golang.org/cl/4517148
2011-06-09math: add sqrt_arm.s and sqrtGoC.go as fallback to soft fp emulationFan Hongjian
5a: add SQRTF and SQRTD 5l: add ASQRTF and ASQRTD Use ARMv7 VFP VSQRT instruction to speed up math.Sqrt R=rsc, dave, m CC=golang-dev https://golang.org/cl/4551082
2011-06-09runtime: improve memmoveQuan Yong Zhai
check memory overlap R=rsc, r, ken, edsrzf CC=golang-dev https://golang.org/cl/4602047
2011-06-09runtime: increase maximum number of windows callbacksAlex Brainman
Fixes #1912. R=rsc CC=golang-dev https://golang.org/cl/4591047
2011-06-07runtime: SysMap uses MAP_FIXED if needed on 64-bit LinuxJonathan Mark
This change was adapted from gccgo's libgo/runtime/mem.c at Ian Taylor's suggestion. It fixes all.bash failing with "address space conflict: map() =" on amd64 Linux with kernel version 2.6.32.8-grsec-2.1.14-modsign-xeon-64. With this change, SysMap will use MAP_FIXED to allocate its desired address space, after first calling mincore to check that there is nothing else mapped there. R=iant, dave, n13m3y3r, rsc CC=golang-dev https://golang.org/cl/4438091
2011-06-02runtime: do not garbage collect windows callbacksAlex Brainman
Fixes #1883. Fixes #1702. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/4532103
2011-06-01gc: make merely referencing an outer variable in a closure not force ↵Luuk van Dijk
heapallocation. before: runtime_test.BenchmarkCallClosure1 20000000 135 ns/op after: runtime_test.BenchmarkCallClosure1 500000000 6 ns/op R=rsc CC=golang-dev https://golang.org/cl/4527091
2011-05-31gc: elide call to runtime.closure for function literals called in-place.Luuk van Dijk
before: runtime_test.BenchmarkCallClosure 5000000 499 ns/op runtime_test.BenchmarkCallClosure1 5000000 681 ns/op after: runtime_test.BenchmarkCallClosure 500000000 5 ns/op runtime_test.BenchmarkCallClosure1 10000000 160 ns/op R=rsc CC=golang-dev https://golang.org/cl/4515167
2011-05-31undo CL 4515163 / 42c3cfa4d64fRuss Cox
breaks Mac build ««« original CL description runtime: use HOST_CC to compile mkversion HOST_CC is set in Make.inc, so use that rather than hardcoding quietgcc R=golang-dev, iant CC=golang-dev https://golang.org/cl/4515163 »»» R=iant CC=golang-dev https://golang.org/cl/4515168
2011-05-31runtime: use HOST_CC to compile mkversionDave Cheney
HOST_CC is set in Make.inc, so use that rather than hardcoding quietgcc R=golang-dev, iant CC=golang-dev https://golang.org/cl/4515163
2011-05-31runtime: reset GOMAXPROCS during testsDmitriy Vyukov
Fix the fact that the test leaves GOMAXPROCS=3 and a running goroutine behind. R=golang-dev, rsc CC=dvyukov, golang-dev https://golang.org/cl/4517121
2011-05-31runtime: save cdecl registers in Windows SEH handlerAlexey Borzenkov
Fixes #1779 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/4566041
2011-05-30pkg: spelling tweaks, I-ZRobert Hencke
also, a few miscellaneous fixes to files outside pkg R=golang-dev, dsymonds, mikioh.mikioh, r CC=golang-dev https://golang.org/cl/4517116
2011-05-26runtime: fix mmap error return on linux.Dmitry Chestnykh
Fixes #1511 again. R=golang-dev, iant CC=golang-dev https://golang.org/cl/4527070
2011-05-22runtime: fix function args not checked warning on armDave Cheney
This tiny nit was driving me nuts R=rsc, ken, r CC=golang-dev https://golang.org/cl/4550069
2011-05-16runtime: make StackSystem part of StackGuardAlexey Borzenkov
Fixes #1779 R=rsc CC=golang-dev https://golang.org/cl/4543052
2011-05-14gc: generalize dst = append(src,...) inlining to arbitrary src and dst ↵Luuk van Dijk
arguments. R=rsc CC=golang-dev https://golang.org/cl/4517057
2011-05-11gc: inline append when len<capLuuk van Dijk
issue 1604 R=rsc, bradfitz CC=golang-dev https://golang.org/cl/4313062
2011-05-10runtime: add newline to "finalizer already set" errorAlbert Strasheim
R=rsc, bradfitz CC=golang-dev https://golang.org/cl/4523047
2011-05-09go/printer, gofmt: fix alignment of "=" in const/var declarationsRobert Griesemer
gofmt -w src misc Fixes #1414. R=rsc, r CC=golang-dev https://golang.org/cl/4456054
2011-05-06runtime: handle out-of-threads on Linux gracefullyAlbert Strasheim
R=rsc CC=golang-dev https://golang.org/cl/4396050
2011-05-02runtime: maybe fix Windows build broken by cgo setenv CLBrad Fitzpatrick
R=rsc CC=golang-dev https://golang.org/cl/4428078
2011-05-02os: make Setenv update C environment variablesBrad Fitzpatrick
Fixes #1569 R=rsc, bradfitzwork CC=golang-dev https://golang.org/cl/4456045
2011-05-02runtime, sync/atomic: fix arm casRuss Cox
Works around bug in kernel implementation on old ARM5 kernels. Bug was fixed on 26 Nov 2007 (between 2.6.23 and 2.6.24) but old kernels persist. Fixes #1750. R=dfc, golang-dev CC=golang-dev https://golang.org/cl/4436072
2011-04-28runtime: fix typo in gc bug fixRuss Cox
This time for sure. R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/4437078
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-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-04-27runtime: fix mkversion to output valid path separatorsPeter Mundy
In a GOROOT path a backslash is a path separator not an escape character. For example, `C:\go`. Fixes gotest error: version.go:3: unknown escape sequence: g R=rsc CC=golang-dev https://golang.org/cl/4437076
2011-04-26runtime: more graceful out-of-memory crashRuss Cox
Used to fault trying to access l->list->next when l->list == nil after MCentral_AllocList. Now prints runtime: out of memory: no room in arena for 65536-byte allocation (536870912 in use) throw: out of memory followed by stack trace. Fixes #1650. R=r, dfc CC=golang-dev https://golang.org/cl/4446062
2011-04-25runtime: fix arm buildDave Cheney
R=rsc, r CC=golang-dev https://golang.org/cl/4438069
2011-04-25runtime: turn "too many EPIPE" into real SIGPIPERuss Cox
Tested on Linux and OS X, amd64 and 386. R=r, iant CC=golang-dev https://golang.org/cl/4452046
2011-04-25runtime: correct out of memory errorRuss Cox
Fixes #1511. R=golang-dev, iant2 CC=golang-dev https://golang.org/cl/4433065
2011-04-23runtime: disable long test (fix arm build)Russ Cox
TBR=r CC=golang-dev https://golang.org/cl/4449051
2011-04-22runtime: stop deadlock test properly (fix arm5 build)Russ Cox
TBR=r CC=golang-dev https://golang.org/cl/4446058
2011-04-21runtime: fix GOMAXPROCS vs garbage collection bugDmitriy Vyukov
Fixes #1715. R=golang-dev, rsc1, rsc CC=golang-dev https://golang.org/cl/4434053
2011-04-21runtime: skip functions with no lines when building src line tableIan Lance Taylor
Avoid getting out of synch when a function, such as main.init, has no associated line number information. Without this the function before main.init can skip the PC all the way to the next function, which will cause the next function's line table to be associated with main.init, and leave subsequent functions with the wrong line numbers. R=rsc CC=golang-dev https://golang.org/cl/4426055
2011-04-21gc: correct handling of unexported method names in embedded interfacesRuss Cox
go/types: update for export data format change reflect: require package qualifiers to match during interface check runtime: require package qualifiers to match during interface check test: fixed bug324, adapt to be silent Fixes #1550. Issue 1536 remains open. R=gri, ken2, r CC=golang-dev https://golang.org/cl/4442071
2011-04-20src/pkg: make package doc comments consistently start with "Package foo".Nigel Tao
R=rsc CC=golang-dev https://golang.org/cl/4442064
2011-04-18reflect: allow Slice of arraysRuss Cox
R=r CC=golang-dev https://golang.org/cl/4444049
2011-04-18reflect: more efficient; cannot Set result of NewValue anymoreRuss Cox
* Reduces malloc counts during gob encoder/decoder test from 6/6 to 3/5. The current reflect uses Set to mean two subtly different things. (1) If you have a reflect.Value v, it might just represent itself (as in v = reflect.NewValue(42)), in which case calling v.Set only changed v, not any other data in the program. (2) If you have a reflect Value v derived from a pointer or a slice (as in x := []int{42}; v = reflect.NewValue(x).Index(0)), v represents the value held there. Changing x[0] affects the value returned by v.Int(), and calling v.Set affects x[0]. This was not really by design; it just happened that way. The motivation for the new reflect implementation was to remove mallocs. The use case (1) has an implicit malloc inside it. If you can do: v := reflect.NewValue(0) v.Set(42) i := v.Int() // i = 42 then that implies that v is referring to some underlying chunk of memory in order to remember the 42; that is, NewValue must have allocated some memory. Almost all the time you are using reflect the goal is to inspect or to change other data, not to manipulate data stored solely inside a reflect.Value. This CL removes use case (1), so that an assignable reflect.Value must always refer to some other piece of data in the program. Put another way, removing this case would make v := reflect.NewValue(0) v.Set(42) as illegal as 0 = 42. It would also make this illegal: x := 0 v := reflect.NewValue(x) v.Set(42) for the same reason. (Note that right now, v.Set(42) "succeeds" but does not change the value of x.) If you really wanted to make v refer to x, you'd start with &x and dereference it: x := 0 v := reflect.NewValue(&x).Elem() // v = *&x v.Set(42) It's pretty rare, except in tests, to want to use NewValue and then call Set to change the Value itself instead of some other piece of data in the program. I haven't seen it happen once yet while making the tree build with this change. For the same reasons, reflect.Zero (formerly reflect.MakeZero) would also return an unassignable, unaddressable value. This invalidates the (awkward) idiom: pv := ... some Ptr Value we have ... v := reflect.Zero(pv.Type().Elem()) pv.PointTo(v) which, when the API changed, turned into: pv := ... some Ptr Value we have ... v := reflect.Zero(pv.Type().Elem()) pv.Set(v.Addr()) In both, it is far from clear what the code is trying to do. Now that it is possible, this CL adds reflect.New(Type) Value that does the obvious thing (same as Go's new), so this code would be replaced by: pv := ... some Ptr Value we have ... pv.Set(reflect.New(pv.Type().Elem())) The changes just described can be confusing to think about, but I believe it is because the old API was confusing - it was conflating two different kinds of Values - and that the new API by itself is pretty simple: you can only Set (or call Addr on) a Value if it actually addresses some real piece of data; that is, only if it is the result of dereferencing a Ptr or indexing a Slice. If you really want the old behavior, you'd get it by translating: v := reflect.NewValue(x) into v := reflect.New(reflect.Typeof(x)).Elem() v.Set(reflect.NewValue(x)) Gofix will not be able to help with this, because whether and how to change the code depends on whether the original code meant use (1) or use (2), so the developer has to read and think about the code. You can see the effect on packages in the tree in https://golang.org/cl/4423043/. R=r CC=golang-dev https://golang.org/cl/4435042
2011-04-17runtime: fix arm5 softfloatRuss Cox
R=dfc, ken2, rsc CC=golang-dev https://golang.org/cl/4446043
2011-04-14pkg/runtime/plan9: Warning remediation, for Plan 9 native.Lucio De Re
. Missing declaration of runtime.brk_(); . Argument v in runtime.SysReserve() is not used; (I'd prefer a Plan 9-type solution...) R=golang-dev, r, r2 CC=golang-dev https://golang.org/cl/4368076
2011-04-14runtime: fix gdb support for channels.Luuk van Dijk
R=rsc CC=golang-dev https://golang.org/cl/4418043
2011-04-14runtime: fix set and not used in chan.cDave Cheney
R=rsc CC=golang-dev https://golang.org/cl/4416042
2011-04-13runtime: drop chan circular linked list in favor of circular bufferRuss Cox
The list elements are already being allocated out of a single memory buffer. We can drop the Link* pointer following and the memory it requires, replacing it with index operations. The change also keeps a channel from containing a pointer back into its own allocation block, which would create a cycle. Blocks involved in cycles are not guaranteed to be finalized properly, and channels depend on finalizers to free OS-level locks on some systems. The self-reference was keeping channels from being garbage collected. runtime-gdb.py will need to be updated in order to dump the content of buffered channels with the new data structure. Fixes #1676. R=ken2, r CC=golang-dev https://golang.org/cl/4411045
2011-03-28runtime: fix gdb support for goroutines.Luuk van Dijk
in gdb, 'info goroutines' and 'goroutine <n> <cmd> were crashing because the 'g' and 'm' structures had changed a bit. R=rsc CC=golang-dev https://golang.org/cl/4289077
2011-03-27build: add all-qemu.bash, handful of arm fixesRuss Cox
R=r CC=golang-dev https://golang.org/cl/4313051
2011-03-27runtime: fix darwin/amd64 thread VM footprintAlexey Borzenkov
On darwin amd64 it was impossible to create more that ~132 threads. While investigating I noticed that go consumes almost 1TB of virtual memory per OS thread and the reason for such a small limit of OS thread was because process was running out of virtual memory. While looking at bsdthread_create I noticed that on amd64 it wasn't using PTHREAD_START_CUSTOM. If you look at http://fxr.watson.org/fxr/source/bsd/kern/pthread_synch.c?v=xnu-1228 you will see that in that case darwin will use stack pointer as stack size, allocating huge amounts of memory for stack. This change fixes the issue and allows for creation of up to 2560 OS threads (which appears to be some Mac OS X limit) with relatively small virtual memory consumption. R=rsc CC=golang-dev https://golang.org/cl/4289075
2011-03-25runtime/pprof: disable test on darwinRuss Cox
Fixes #1641. Actually it side steps the real issue, which is that the setitimer(2) implementation on OS X is not useful for profiling of multi-threaded programs. I filed the below using the Apple Bug Reporter. /* Filed as Apple Bug Report #9177434. This program creates a new pthread that loops, wasting cpu time. In the main pthread, it sleeps on a condition that will never come true. Before doing so it sets up an interval timer using ITIMER_PROF. The handler prints a message saying which thread it is running on. POSIX does not specify which thread should receive the signal, but in order to be useful in a user-mode self-profiler like pprof or gprof http://code.google.com/p/google-perftools http://www.delorie.com/gnu/docs/binutils/gprof_25.html it is important that the thread that receives the signal is the one whose execution caused the timer to expire. Linux and FreeBSD handle this by sending the signal to the process's queue but delivering it to the current thread if possible: http://lxr.linux.no/linux+v2.6.38/kernel/signal.c#L802 807 /* 808 * Now find a thread we can wake up to take the signal off the queue. 809 * 810 * If the main thread wants the signal, it gets first crack. 811 * Probably the least surprising to the average bear. 812 * / http://fxr.watson.org/fxr/source/kern/kern_sig.c?v=FREEBSD8;im=bigexcerpts#L1907 1914 /* 1915 * Check if current thread can handle the signal without 1916 * switching context to another thread. 1917 * / On those operating systems, this program prints: $ ./a.out signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread signal on cpu-chewing looper thread $ The OS X kernel does not have any such preference. Its get_signalthread does not prefer current_thread(), in contrast to the other two systems, so the signal gets delivered to the first thread in the list that is able to handle it, which ends up being the main thread in this experiment. http://fxr.watson.org/fxr/source/bsd/kern/kern_sig.c?v=xnu-1456.1.26;im=excerpts#L1666 $ ./a.out signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread signal on sleeping main thread $ The fix is to make get_signalthread use the same heuristic as Linux and FreeBSD, namely to use current_thread() if possible before scanning the process thread list. */ #include <sys/time.h> #include <sys/signal.h> #include <pthread.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <string.h> static void handler(int); static void* looper(void*); static pthread_t pmain, ploop; int main(void) { struct itimerval it; struct sigaction sa; pthread_cond_t cond; pthread_mutex_t mu; memset(&sa, 0, sizeof sa); sa.sa_handler = handler; sa.sa_flags = SA_RESTART; memset(&sa.sa_mask, 0xff, sizeof sa.sa_mask); sigaction(SIGPROF, &sa, 0); pmain = pthread_self(); pthread_create(&ploop, 0, looper, 0); memset(&it, 0, sizeof it); it.it_interval.tv_usec = 10000; it.it_value = it.it_interval; setitimer(ITIMER_PROF, &it, 0); pthread_mutex_init(&mu, 0); pthread_mutex_lock(&mu); pthread_cond_init(&cond, 0); for(;;) pthread_cond_wait(&cond, &mu); return 0; } static void handler(int sig) { static int nsig; pthread_t p; p = pthread_self(); if(p == pmain) printf("signal on sleeping main thread\n"); else if(p == ploop) printf("signal on cpu-chewing looper thread\n"); else printf("signal on %p\n", (void*)p); if(++nsig >= 10) exit(0); } static void* looper(void *v) { for(;;); } R=r CC=golang-dev https://golang.org/cl/4273113
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 13:08:06 +0000