An error occurred fetching the project authors.
- 05 Sep, 2014 1 commit
-
-
Russ Cox authored
I did this just to clean things up, but it will be important when we drop the pkg directory later. LGTM=bradfitz R=r, bradfitz CC=golang-codereviews https://golang.org/cl/132600043
-
- 27 Aug, 2014 1 commit
-
-
Russ Cox authored
To date, the C compilers and Go compilers differed only in how values were returned from functions. This made it difficult to call Go from C or C from Go if return values were involved. It also made assembly called from Go and assembly called from C different. This CL changes the C compiler to use the Go conventions, passing results on the stack, after the arguments. [Exception: this does not apply to C ... functions, because you can't know where on the stack the arguments end.] By doing this, the CL makes it possible to rewrite C functions into Go one at a time, without worrying about which languages call that function or which languages it calls. This CL also updates all the assembly files in package runtime to use the new conventions. Argument references of the form 40(SP) have been rewritten to the form name+10(FP) instead, and there are now Go func prototypes for every assembly function called from C or Go. This means that 'go vet runtime' checks effectively every assembly function, and go vet's output was used to automate the bulk of the conversion. Some functions, like seek and nsec on Plan 9, needed to be rewritten. Many assembly routines called from C were reading arguments incorrectly, using MOVL instead of MOVQ or vice versa, especially on the less used systems like openbsd. These were found by go vet and have been corrected too. If we're lucky, this may reduce flakiness on those systems. Tested on: darwin/386 darwin/amd64 linux/arm linux/386 linux/amd64 If this breaks another system, the bug is almost certainly in the sys_$GOOS_$GOARCH.s file, since the rest of the CL is tested by the combination of the above systems. LGTM=dvyukov, iant R=golang-codereviews, 0intro, dave, alex.brainman, dvyukov, iant CC=golang-codereviews, josharian, r https://golang.org/cl/135830043
-
- 26 Jun, 2014 1 commit
-
-
Russ Cox authored
The runtime has historically held two dedicated values g (current goroutine) and m (current thread) in 'extern register' slots (TLS on x86, real registers backed by TLS on ARM). This CL removes the extern register m; code now uses g->m. On ARM, this frees up the register that formerly held m (R9). This is important for NaCl, because NaCl ARM code cannot use R9 at all. The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected: BenchmarkBinaryTree17 5491374955 5471024381 -0.37% BenchmarkFannkuch11 4357101311 4275174828 -1.88% BenchmarkGobDecode 11029957 11364184 +3.03% BenchmarkGobEncode 6852205 6784822 -0.98% BenchmarkGzip 650795967 650152275 -0.10% BenchmarkGunzip 140962363 141041670 +0.06% BenchmarkHTTPClientServer 71581 73081 +2.10% BenchmarkJSONEncode 31928079 31913356 -0.05% BenchmarkJSONDecode 117470065 113689916 -3.22% BenchmarkMandelbrot200 6008923 5998712 -0.17% BenchmarkGoParse 6310917 6327487 +0.26% BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17% BenchmarkRegexpMatchHard_1K 168977 169244 +0.16% BenchmarkRevcomp 935294971 914060918 -2.27% BenchmarkTemplate 145917123 148186096 +1.55% Minux previous reported larger variations, but these were caused by run-to-run noise, not repeatable slowdowns. Actual code changes by Minux. I only did the docs and the benchmarking. LGTM=dvyukov, iant, minux R=minux, josharian, iant, dave, bradfitz, dvyukov CC=golang-codereviews https://golang.org/cl/109050043
-
- 07 Aug, 2013 1 commit
-
-
Keith Randall authored
Remove NOPROF/DUPOK from everything. Edits done with a script, except pclinetest.asm which depended on the DUPOK flag on main(). R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/12613044
-
- 11 Jul, 2013 1 commit
-
-
Shenghou Ma authored
Fixes #3250. R=rsc CC=golang-dev https://golang.org/cl/10757044
-
- 15 Mar, 2013 2 commits
-
-
Russ Cox authored
This provides a way to generate core dumps when people need them. The settings are: GOTRACEBACK=0 no traceback on panic, just exit GOTRACEBACK=1 default - traceback on panic, then exit GOTRACEBACK=2 traceback including runtime frames on panic, then exit GOTRACEBACK=crash traceback including runtime frames on panic, then crash Fixes #3257. R=golang-dev, devon.odell, r, daniel.morsing, ality CC=golang-dev https://golang.org/cl/7666044
-
Russ Cox authored
NEGL does a negation of the bottom 32 bits and then zero-extends to 64 bits, resulting in a negative 32-bit number but a positive 64-bit number. NEGQ does a full 64-bit negation, so that the result is negative both as a 32-bit and as a 64-bit number. This doesn't matter for the functions that are declared to return int32. It only matters for the ones that return int64 or void* [sic]. This will fix the current incorrect error in the OpenBSD/amd64 build. The build will still be broken, but it won't report a bogus error. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/7536046
-
- 14 Mar, 2013 1 commit
-
-
Dmitriy Vyukov authored
vs tip: benchmark old ns/op new ns/op delta BenchmarkTCP4Persistent 67786 33175 -51.06% BenchmarkTCP4Persistent-2 49085 31227 -36.38% BenchmarkTCP4PersistentTimeout 69265 32565 -52.98% BenchmarkTCP4PersistentTimeout-2 49217 32588 -33.79% vs old scheduler: benchmark old ns/op new ns/op delta BenchmarkTCP4Persistent 63517 33175 -47.77% BenchmarkTCP4Persistent-2 54760 31227 -42.97% BenchmarkTCP4PersistentTimeout 63234 32565 -48.50% BenchmarkTCP4PersistentTimeout-2 56956 32588 -42.78% R=golang-dev, bradfitz, devon.odell, mikioh.mikioh, iant, rsc CC=golang-dev, pabuhr https://golang.org/cl/7569043
-
- 12 Mar, 2013 1 commit
-
-
Keith Randall authored
Uses AES hardware instructions on 386/amd64 to implement a fast hash function. Incorporates a random key to thwart hash collision DOS attacks. Depends on CL#7548043 for new assembly instructions. Update #3885 Helps some by making hashing faster. Go time drops from 0.65s to 0.51s. R=rsc, r, bradfitz, remyoudompheng, khr, dsymonds, minux.ma, elias.naur CC=golang-dev https://golang.org/cl/7543043
-
- 22 Dec, 2012 1 commit
-
-
Russ Cox authored
When we release memory to the OS, if the OS doesn't want us to release it (for example, because the program executed mlockall(MCL_FUTURE)), madvise will fail. Ignore the failure instead of crashing. Fixes #3435. R=ken2 CC=golang-dev https://golang.org/cl/6998052
-
- 18 Dec, 2012 1 commit
-
-
Jingcheng Zhang authored
runtime: use "mp" and "gp" instead of "m" and "g" for local variable name to avoid confusion with the global "m" and "g". R=golang-dev, minux.ma, rsc CC=bradfitz, golang-dev https://golang.org/cl/6939064
-
- 04 Sep, 2012 1 commit
-
-
Alan Donovan authored
Signal handlers are global resources but many language environments (Go, C++ at Google, etc) assume they have sole ownership of a particular handler. Signal handlers in mixed-language applications must therefore be robust against unexpected delivery of certain signals, such as SIGPROF. The default Go signal handler runtime·sigtramp assumes that it will never be called on a non-Go thread, but this assumption is violated by when linking in C++ code that spawns threads. Specifically, the handler asserts the thread has an associated "m" (Go scheduler). This CL is a very simple workaround: discard SIGPROF delivered to non-Go threads. runtime.badsignal(int32) now receives the signal number; if it returns without panicking (e.g. sig==SIGPROF) the signal is discarded. I don't think there is any really satisfactory solution to the problem of signal-based profiling in a mixed-language application. It's not only the issue of handler clobbering, but also that a C++ SIGPROF handler called in a Go thread can't unwind the Go stack (and vice versa). The best we can hope for is not crashing. Note: - I've ported this to all POSIX platforms, except ARM-linux which already ignores unexpected signals on m-less threads. - I've avoided tail-calling runtime.badsignal because AFAICT the 6a/6l don't support it. - I've avoided hoisting 'push sig' (common to both function calls) because it makes the code harder to read. - Fixed an (apparently incorrect?) docstring. R=iant, rsc, minux.ma CC=golang-dev https://golang.org/cl/6498057
-
- 05 Jun, 2012 1 commit
-
-
Russ Cox authored
Thanks to Dave Cheney for the magic words "comm page". benchmark old ns/op new ns/op delta BenchmarkNow 197 33 -83.05% This should make profiling a little better on OS X. The raw time saved is unlikely to matter: what likely matters more is that it seems like OS X sends profiling signals on the way out of system calls more often than it should; avoiding the system call should increase the accuracy of cpu profiles. The 386 version would be similar but needs to do different math for CPU speeds less than 1 GHz. (Apparently Apple has never shipped a 64-bit CPU with such a slow clock.) R=golang-dev, bradfitz, dave, minux.ma, r CC=golang-dev https://golang.org/cl/6275056
-
- 30 Apr, 2012 1 commit
-
-
Shenghou Ma authored
also gives clear error when bsdthread_register fails on Darwin Fixes #2992. R=rsc, krautz CC=golang-dev https://golang.org/cl/5966067
-
- 12 Mar, 2012 1 commit
-
-
Russ Cox authored
It's the best we can do before Go 1. For issue 3250; not a fix but at least less mysterious. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/5797068
-
- 08 Mar, 2012 1 commit
-
-
Russ Cox authored
When a very low-level system call that should never fail does fail, we call notok, which crashes the program. Often, we are then left with only the program counter as information about the crash, and it is in notok. Instead, inline calls to notok (it is just one instruction on most systems) so that the program counter will tell us which system call is unhappy. R=golang-dev, gri, minux.ma, bradfitz CC=golang-dev https://golang.org/cl/5792048
-
- 28 Feb, 2012 1 commit
-
-
Russ Cox authored
Work around profiling kernel bug with signal masks. Still broken on 64-bit Snow Leopard kernel, but I think we can ignore that one and let people upgrade to Lion. Add new trivial tools addr2line and objdump to take the place of the GNU tools of the same name, since those are not installed on OS X. Adapt pprof to invoke 'go tool addr2line' and 'go tool objdump' if the system tools do not exist. Clean up disassembly of base register on amd64. Fixes #2008. R=golang-dev, bradfitz, mikioh.mikioh, r, iant CC=golang-dev https://golang.org/cl/5697066
-
- 23 Feb, 2012 1 commit
-
-
Russ Cox authored
Fixes #3101 (darwin). R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/5693044
-
- 19 Jan, 2012 2 commits
-
-
Shenghou Ma authored
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5532100
-
Dave Cheney authored
SysUnused is a direct call to madvise MADV_FREE. R=sebastien.paolacci, rsc, minux.ma CC=golang-dev https://golang.org/cl/5531073
-
- 11 Jan, 2012 1 commit
-
-
Shenghou Ma authored
pkg/runtime/sys_darwin_amd64.s: fixes syscall select nr pkg/runtime/sys_linux_arm.s: uses newselect instead of the now unimplemented (old) select, also fixes the wrong div/mod statements in runtime.usleep. Fixes #2633 R=golang-dev, dave, rsc CC=golang-dev https://golang.org/cl/5504096
-
- 19 Dec, 2011 1 commit
-
-
Russ Cox authored
This is like the ill-fated CL 5493063 except that I have written a shell script (autogen.sh) instead of thinking I could possibly write a correct Makefile. R=golang-dev, r CC=golang-dev https://golang.org/cl/5496075
-
- 16 Dec, 2011 3 commits
-
-
Russ Cox authored
That was the last build that was close to working. I will try that change again next week. Make is being very subtle today. At the reverted-to CL, the ARM traceback appears to be broken. I'll look into that next week too. R=golang-dev, r CC=golang-dev https://golang.org/cl/5492063
-
Russ Cox authored
R=golang-dev, r, r CC=golang-dev https://golang.org/cl/5493063
-
Russ Cox authored
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
-
- 30 Nov, 2011 1 commit
-
-
Russ Cox authored
R=r, bradfitz, gri, dsymonds, iant CC=golang-dev https://golang.org/cl/5392041
-
- 03 Nov, 2011 1 commit
-
-
Russ Cox authored
runtime knows how to get the time of day without allocating memory. R=golang-dev, dsymonds, dave, hectorchu, r, cw CC=golang-dev https://golang.org/cl/5297078
-
- 30 Sep, 2011 1 commit
-
-
Russ Cox authored
Running test/garbage/parser.out. On a 4-core Lenovo X201s (Linux): 31.12u 0.60s 31.74r 1 cpu, no atomics 32.27u 0.58s 32.86r 1 cpu, atomic instructions 33.04u 0.83s 27.47r 2 cpu On a 16-core Xeon (Linux): 33.08u 0.65s 33.80r 1 cpu, no atomics 34.87u 1.12s 29.60r 2 cpu 36.00u 1.87s 28.43r 3 cpu 36.46u 2.34s 27.10r 4 cpu 38.28u 3.85s 26.92r 5 cpu 37.72u 5.25s 26.73r 6 cpu 39.63u 7.11s 26.95r 7 cpu 39.67u 8.10s 26.68r 8 cpu On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5): 39.43u 1.45s 41.27r 1 cpu, no atomics 43.98u 2.95s 38.69r 2 cpu On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1): 48.81u 2.12s 51.76r 1 cpu, no atomics 57.15u 4.72s 51.54r 2 cpu The handoff algorithm is really only good for two cores. Beyond that we will need to so something more sophisticated, like have each core hand off to the next one, around a circle. Even so, the code is a good checkpoint; for now we'll limit the number of gc procs to at most 2. R=dvyukov CC=golang-dev https://golang.org/cl/4641082
-
- 25 Apr, 2011 1 commit
-
-
Russ Cox authored
Tested on Linux and OS X, amd64 and 386. R=r, iant CC=golang-dev https://golang.org/cl/4452046
-
- 27 Mar, 2011 1 commit
-
-
Alexey Borzenkov authored
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
-
- 23 Mar, 2011 1 commit
-
-
Russ Cox authored
R=r CC=golang-dev https://golang.org/cl/4273097
-
- 23 Feb, 2011 1 commit
-
-
Russ Cox authored
The existing code assumed that signals only arrived while executing on the goroutine stack (g == m->curg), not while executing on the scheduler stack (g == m->g0). Most of the signal handling trampolines correctly saved and restored g already, but the sighandler C code did not have access to it. Some rewriting of assembly to make the various implementations as similar as possible. Will need to change Windows too but I don't understand how sigtramp gets called there. R=r CC=golang-dev https://golang.org/cl/4203042
-
- 28 Jan, 2011 1 commit
-
-
Russ Cox authored
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
-
- 16 Dec, 2010 1 commit
-
-
Russ Cox authored
The other operating systems already ignore write failures. Fixes #1279. R=r, r2 CC=golang-dev https://golang.org/cl/3723041
-
- 04 Nov, 2010 1 commit
-
-
Russ Cox authored
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
-
- 29 Sep, 2010 1 commit
-
-
Russ Cox authored
R=r, iant, robert.swiecki, rsc1 CC=golang-dev https://golang.org/cl/1904044
-
- 07 Sep, 2010 1 commit
-
-
Russ Cox authored
Old code was using recursion to traverse object graph. New code uses an explicit stack, cutting the per-pointer footprint to two words during the recursion and avoiding the standard allocator and stack splitting code. in test/garbage: Reduces parser runtime by 2-3% Reduces Peano runtime by 40% Increases tree runtime by 4-5% R=r CC=golang-dev https://golang.org/cl/2150042
-
- 05 Aug, 2010 1 commit
-
-
Russ Cox authored
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
-
- 29 Apr, 2010 1 commit
-
-
Russ Cox authored
Fixes #549. R=adg CC=golang-dev https://golang.org/cl/1019042
-
- 08 Apr, 2010 1 commit
-
-
Russ Cox authored
Could not take a signal on threads other than the main thread. If you look at the spinning binary with dtrace, you can see a fault happening over and over: $ dtrace -n ' fbt::user_trap:entry /execname=="boot32" && self->count < 10/ { self->count++; printf("%s %x %x %x %x", probefunc, arg1, arg2, arg3, arg4); stack(); tracemem(arg4, 256); }' dtrace: description 'fbt::user_trap:entry ' matched 1 probe CPU ID FUNCTION:NAME 1 17015 user_trap:entry user_trap 0 10 79af0a0 79af0a0 mach_kernel`lo_alltraps+0x12a 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 0: 0e 00 00 00 37 00 00 00 00 00 00 00 1f 00 00 00 ....7........... 10: 1f 00 00 00 a8 33 00 00 00 00 00 01 00 00 00 00 .....3.......... 20: 98 ba dc fe 07 09 00 00 00 00 00 00 98 ba dc fe ................ 30: 06 00 00 00 0d 00 00 00 34 00 00 00 9e 1c 00 00 ........4....... 40: 17 00 00 00 00 02 00 00 ac 30 00 00 1f 00 00 00 .........0...... 50: 00 00 00 00 00 00 00 00 0d 00 00 00 e0 e6 29 00 ..............). 60: 34 00 00 00 00 00 00 00 9e 1c 00 00 00 00 00 00 4............... 70: 17 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 ................ 80: ac 30 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 .0.............. 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0: 48 00 00 00 10 00 00 00 85 00 00 00 a0 f2 29 00 H.............). b0: 69 01 00 02 00 00 00 00 e6 93 04 82 ff 7f 00 00 i............... c0: 2f 00 00 00 00 00 00 00 06 02 00 00 00 00 00 00 /............... d0: 78 ee 42 01 01 00 00 00 1f 00 00 00 00 00 00 00 x.B............. e0: 00 ed 9a 07 00 00 00 00 00 00 00 00 00 00 00 00 ................ f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ... The memory dump shows a 32-bit exception frame: x86_saved_state32 gs = 0x37 fs = 0 es = 0x1f ds = 0x1f edi = 0x33a8 esi = 0x01000000 ebp = 0 cr2 = 0xfedcba98 ebx = 0x0907 edx = 0 ecx = 0xfedcba98 eax = 0x06 trapno = 0x0d err = 0x34 eip = 0x1c9e cs = 0x17 efl = 0x0200 uesp = 0x30ac ss = 0x1f The cr2 of 0xfedcba98 is the address that the new thread read to cause the fault, but note that the trap is now a GP fault with error code 0x34, meaning it's moved past the cr2 problem and on to an invaild segment selector. The 0x34 is suspiciously similar to the 0x37 in gs, and sure enough, OS X forces gs to have that value in the signal handler, and if your thread hasn't set up that segment (known as USER_CTHREAD), you'll fault on the IRET into the signal handler and never be able to handle a signal. The kernel bug is that it forces segment 0x37 without making sure it is a valid segment. Leopard also forced 0x37 but had the courtesy to set it up first. Since OS X requires us to set up that segment (using the thread_fast_set_cthread_self system call), we might as well use it instead of the more complicated i386_set_ldt call to set up our per-OS thread storage. Also add some more zeros to bsdthread_register for new arguments in Snow Leopard (apparently unnecessary, but being careful). Fixes #510. R=r CC=golang-dev https://golang.org/cl/824046
-