Skip to content

G
go
Switch branch/tag
  1. 20 Mar, 2015 6 commits
  3. 19 Mar, 2015 15 commits
  5. 18 Mar, 2015 10 commits
  7. 17 Mar, 2015 9 commits
    • Robert Griesemer's avatar
      math/big: clearer semantics for Float.Scan · db96e682
      Robert Griesemer authored 
      Change-Id: I72e8389ec080be8a0119f98df898de6f5510fa4d
Reviewed-on: https://go-review.googlesource.com/7693Reviewed-by: default avatarAlan Donovan <adonovan@google.com>
      db96e682
    • David Chase's avatar
      cmd/internal/gc: add a comment to esc.go · bc149897
      David Chase authored 
      Change-Id: I19e6542e7d79d60e39d62339da51a827c5aa6d3b
Reviewed-on: https://go-review.googlesource.com/7668Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      bc149897
    • Russ Cox's avatar
      runtime: fix writebarrier throw in lock_sema · 87ec06f9
      Russ Cox authored 
      The value in question is really a bit pattern
(a pointer with extra bits thrown in),
so treat it as a uintptr instead, avoiding the
generation of a write barrier when there
might not be a p.

Also add the obligatory //go:nowritebarrier.

Change-Id: I4ea097945dd7093a140f4740bcadca3ce7191971
Reviewed-on: https://go-review.googlesource.com/7667Reviewed-by: default avatarRick Hudson <rlh@golang.org>
Reviewed-by: default avatarAustin Clements <austin@google.com>
      87ec06f9
    • Rick Hudson's avatar
      runtime: Remove write barriers during STW. · 41dbcc19
      Rick Hudson authored 
      The GC assumes that there will be no asynchronous write barriers when
the world is stopped. This keeps the synchronization between write
barriers and the GC simple. However, currently, there are a few places
in runtime code where this assumption does not hold.
The GC stops the world by collecting all Ps, which stops all user Go
code, but small parts of the runtime can run without a P. For example,
the code that releases a P must still deschedule its G onto a runnable
queue before stopping. Similarly, when a G returns from a long-running
syscall, it must run code to reacquire a P.
Currently, this code can contain write barriers. This can lead to the
GC collecting reachable objects if something like the following
sequence of events happens:
1. GC stops the world by collecting all Ps.
2. G #1 returns from a syscall (for example), tries to install a
pointer to object X, and calls greyobject on X.
3. greyobject on G #1 marks X, but does not yet add it to a write
buffer. At this point, X is effectively black, not grey, even though
it may point to white objects.
4. GC reaches X through some other path and calls greyobject on X, but
greyobject does nothing because X is already marked.
5. GC completes.
6. greyobject on G #1 adds X to a work buffer, but it's too late.
7. Objects that were reachable only through X are incorrectly collected.
To fix this, we check the invariant that no asynchronous write
barriers happen when the world is stopped by checking that write
barriers always have a P, and modify all currently known sources of
these writes to disable the write barrier. In all modified cases this
is safe because the object in question will always be reachable via
some other path.

Some of the trace code was turned off, in particular the
code that traces returning from a syscall. The GC assumes
that as far as the heap is concerned the thread is stopped
when it is in a syscall. Upon returning the trace code
must not do any heap writes for the same reasons discussed
above.

Fixes #10098
Fixes #9953
Fixes #9951
Fixes #9884

May relate to #9610 #9771

Change-Id: Ic2e70b7caffa053e56156838eb8d89503e3c0c8a
Reviewed-on: https://go-review.googlesource.com/7504Reviewed-by: default avatarAustin Clements <austin@google.com>
      41dbcc19
    • David Crawshaw's avatar
      runtime: copy env strings on startup · ce9b512c
      David Crawshaw authored 
      Some versions of libc, in this case Android's bionic, point environ
directly at the envp memory.

https://android.googlesource.com/platform/bionic/+/master/libc/bionic/libc_init_common.cpp#104

The Go runtime does something surprisingly similar, building the
runtime's envs []string using gostringnocopy. Both libc and the Go
runtime reusing memory interacts badly. When syscall.Setenv uses cgo
to call setenv(3), C modifies the underlying memory of a Go string.

This manifests on android/arm. With GOROOT=/data/local/tmp, a
runtime test calls syscall.Setenv("/os"), resulting in
runtime.GOROOT()=="/os\x00a/local/tmp/goroot".

Avoid this by copying environment string memory into Go.

Covered by runtime.TestFixedGOROOT on android/arm.

Change-Id: Id0cf9553969f587addd462f2239dafca1cf371fa
Reviewed-on: https://go-review.googlesource.com/7663Reviewed-by: default avatarKeith Randall <khr@golang.org>
      ce9b512c
    • Robert Griesemer's avatar
      math/big: cleaner handling of exponent under/overflow · 00c73f5c
      Robert Griesemer authored 
      Fixed several corner-case bugs and added corresponding tests.

Change-Id: I23096b9caeeff0956f65ab59fa91e168d0e47bb8
Reviewed-on: https://go-review.googlesource.com/7001Reviewed-by: default avatarAlan Donovan <adonovan@google.com>
      00c73f5c
    • Dmitry Vyukov's avatar
      runtime: fix comment · 2e7f0a00
      Dmitry Vyukov authored 
      IRIW requires 4 threads: first writes x, second writes y,
third reads x and y, fourth reads y and x.
This is Peterson/Dekker mutual exclusion algorithm based on
critical store-load sequences:
http://en.wikipedia.org/wiki/Dekker's_algorithm
http://en.wikipedia.org/wiki/Peterson%27s_algorithm

Change-Id: I30a00865afbe895f7617feed4559018f81ff4528
Reviewed-on: https://go-review.googlesource.com/7561Reviewed-by: default avatarAustin Clements <austin@google.com>
Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      2e7f0a00
    • Dmitry Vyukov's avatar
      runtime: remove futile wakeups from trace · 4396ea96
      Dmitry Vyukov authored 
      Channels and sync.Mutex'es allow another goroutine to acquire resource
ahead of an unblocked goroutine. This is good for performance, but
leads to futile wakeups (the unblocked goroutine needs to block again).
Futile wakeups caused user confusion during the very first evaluation
of tracing functionality on a real server (a goroutine as if acquires a mutex
in a loop, while there is no loop in user code).

This change detects futile wakeups on channels and emits a special event
to denote the fact. Later parser finds entire wakeup sequences
(unblock->start->block) and removes them.

sync.Mutex will be supported in a separate change.

Change-Id: Iaaaee9d5c0921afc62b449a97447445030ac19d3
Reviewed-on: https://go-review.googlesource.com/7380Reviewed-by: default avatarKeith Randall <khr@golang.org>
      4396ea96
    • David Crawshaw's avatar
      runtime/cgo: catch EXC_BAD_ACCESS on darwin/arm · 1b49a86e
      David Crawshaw authored 
      The Go builders (and standard development cycle) for programs on iOS
require running the programs under lldb. Unfortunately lldb intercepts
SIGSEGV and will not give it back.

https://llvm.org/bugs/show_bug.cgi?id=22868

We get around this by never letting lldb see the SIGSEGV. On darwin,
Unix signals are emulated on top of mach exceptions. The debugger
registers a task-level mach exception handler. We register a
thread-level exception handler which acts as a faux signal handler.
The thread-level handler gets precedence over the task-level handler,
so we can turn the exception EXC_BAD_ACCESS into a panic before lldb
can see it.

Fixes #10043

Change-Id: I64d7c310dfa7ecf60eb1e59f094966520d473335
Reviewed-on: https://go-review.googlesource.com/7072Reviewed-by: default avatarMinux Ma <minux@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
      1b49a86e
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7