An error occurred fetching the project authors.
  1. 05 Sep, 2014 1 commit
  2. 27 Aug, 2014 1 commit
    • Russ Cox's avatar
      cmd/cc, runtime: convert C compilers to use Go calling convention · 25f6b02a
      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
      25f6b02a
  3. 26 Jun, 2014 1 commit
    • Russ Cox's avatar
      all: remove 'extern register M *m' from runtime · 89f185fe
      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
      89f185fe
  4. 07 Aug, 2013 1 commit
  5. 11 Jul, 2013 1 commit
  6. 15 Mar, 2013 2 commits
    • Russ Cox's avatar
      runtime: accept GOTRACEBACK=crash to mean 'crash after panic' · 5146a93e
      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
      5146a93e
    • Russ Cox's avatar
      runtime: use 64-bit negative error code on 64-bit machines · e3c7a9db
      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
      e3c7a9db
  7. 14 Mar, 2013 1 commit
    • Dmitriy Vyukov's avatar
      runtime: integrated network poller for darwin · 0bee99ab
      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
      0bee99ab
  8. 12 Mar, 2013 1 commit
    • Keith Randall's avatar
      runtime: faster & safer hash function · a5d40241
      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
      a5d40241
  9. 22 Dec, 2012 1 commit
  10. 18 Dec, 2012 1 commit
  11. 04 Sep, 2012 1 commit
    • Alan Donovan's avatar
      runtime: discard SIGPROF delivered to non-Go threads. · 532dee38
      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
      532dee38
  12. 05 Jun, 2012 1 commit
    • Russ Cox's avatar
      runtime: use OS X vsyscall for gettimeofday (amd64) · 3a66bc41
      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
      3a66bc41
  13. 30 Apr, 2012 1 commit
  14. 12 Mar, 2012 1 commit
  15. 08 Mar, 2012 1 commit
    • Russ Cox's avatar
      runtime: inline calls to notok · 36aa7d4d
      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
      36aa7d4d
  16. 28 Feb, 2012 1 commit
    • Russ Cox's avatar
      runtime/pprof: support OS X CPU profiling · 6e2ae0a1
      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
      6e2ae0a1
  17. 23 Feb, 2012 1 commit
  18. 19 Jan, 2012 2 commits
  19. 11 Jan, 2012 1 commit
  20. 19 Dec, 2011 1 commit
  21. 16 Dec, 2011 3 commits
    • Russ Cox's avatar
      runtime: hg revert -r 6ec0a5c12d75 · 86dcc431
      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
      86dcc431
    • Russ Cox's avatar
      runtime: separate out auto-generated files · bd9243da
      Russ Cox authored
      R=golang-dev, r, r
      CC=golang-dev
      https://golang.org/cl/5493063
      bd9243da
    • Russ Cox's avatar
      runtime: make more build-friendly · 851f3013
      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
      851f3013
  22. 30 Nov, 2011 1 commit
  23. 03 Nov, 2011 1 commit
  24. 30 Sep, 2011 1 commit
    • Russ Cox's avatar
      runtime: parallelize garbage collector mark + sweep · d324f214
      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
      d324f214
  25. 25 Apr, 2011 1 commit
  26. 27 Mar, 2011 1 commit
    • Alexey Borzenkov's avatar
      runtime: fix darwin/amd64 thread VM footprint · 59a89268
      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
      59a89268
  27. 23 Mar, 2011 1 commit
  28. 23 Feb, 2011 1 commit
    • Russ Cox's avatar
      runtime: pass to signal handler value of g at time of signal · 690291a2
      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
      690291a2
  29. 28 Jan, 2011 1 commit
    • Russ Cox's avatar
      runtime: simpler heap map, memory allocation · 4608feb1
      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
      4608feb1
  30. 16 Dec, 2010 1 commit
  31. 04 Nov, 2010 1 commit
    • Russ Cox's avatar
      runtime: ,s/[a-zA-Z0-9_]+/runtime·&/g, almost · 68b4255a
      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
      68b4255a
  32. 29 Sep, 2010 1 commit
  33. 07 Sep, 2010 1 commit
    • Russ Cox's avatar
      runtime: use manual stack for garbage collection · d4cc557b
      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
      d4cc557b
  34. 05 Aug, 2010 1 commit
  35. 29 Apr, 2010 1 commit
  36. 08 Apr, 2010 1 commit
    • Russ Cox's avatar
      runtime: work around kernel bug in Snow Leopard signal handling · 2f0cae46
      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
      2f0cae46