- 12 Nov, 2015 22 commits
-
-
Yao Zhang authored
Change-Id: I5129a5b9dbbc57d97da723c2fc247bd28f951817 Reviewed-on: https://go-review.googlesource.com/14451Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: Ibe6c345afd4cbae7e2542a350043fbb6b81d5678 Reviewed-on: https://go-review.googlesource.com/14450Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Syscall getdents64 is relatively new in linux/mips64, only since kernel version 3.10. To support older kernel, syscall getdents is used for mips64. Change-Id: I892b05dff7d93e7ddb0d700abd6a5e6d4084ab4c Reviewed-on: https://go-review.googlesource.com/14449Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: I574a2b702bb3db596f890ae7b18fb4bc1fd358d5 Reviewed-on: https://go-review.googlesource.com/14448Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Linux/mips64 uses a different signal table. To avoid code copying, signal table is factored out from signal_linux.go to sigtab_linux_generic.go. And a mips64-specific version is added. Change-Id: I842d7a7467c330bf772855fde01aecc77a42316b Reviewed-on: https://go-review.googlesource.com/14993Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Yao Zhang authored
Linux/mips64 has a different sigset type and some different constants. os2_linux.go is renamed to os2_linux_generic.go, and not used in mips64. The corresponding file os2_linux_mips64x.go is added. Change-Id: Ief83845a2779f7fe048d236d3c7da52b627ab533 Reviewed-on: https://go-review.googlesource.com/14992Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Linux/mips64 uses a different type of sigset. To deal with it, related functions in os1_linux.go is refactored to os1_linux_generic.go (used for non-mips64 architectures), and os1_linux_mips64x.go (only used in mips64{,le}), to avoid code copying. Change-Id: I5cadfccd86bfc4b30bf97e12607c3c614903ea4c Reviewed-on: https://go-review.googlesource.com/14991Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Yao Zhang authored
Change-Id: I381c03d957a0dccae5f655f02e92760e5c0e9629 Reviewed-on: https://go-review.googlesource.com/14929Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
files for unsupported architectures are deleted, as it would require changing cmd/dist to recognize their names as build tags (probably need a separated CL). Change-Id: Ifd164b014867d39b4924d1b859fb84317dce4ab0 Reviewed-on: https://go-review.googlesource.com/14928Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: I14b537922b97d4bce9e0523d98a822da906348f1 Reviewed-on: https://go-review.googlesource.com/14447Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: Ia496470e48b3c5d39fb9fef99fac356dfb73a949 Reviewed-on: https://go-review.googlesource.com/14927Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: I2eaf0658771a0ff788429e2f503d116531166315 Reviewed-on: https://go-review.googlesource.com/16834Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: I9e94027ef66c88007107de2b2b75c3d7cf1352af Reviewed-on: https://go-review.googlesource.com/14467Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
The actual cgo is not supported for now. This is just the cgo command. Change-Id: I25625100ee552971f47e681b7d613cba16a2132f Reviewed-on: https://go-review.googlesource.com/14446Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
It is based on ppc64 compiler. Change-Id: I15a101df05f2919ba5292136957ba0009227d067 Reviewed-on: https://go-review.googlesource.com/14445Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Only internal linking without cgo is supported for now. Change-Id: Ie6074a8ff3ec13605b72028f2d60758034f87185 Reviewed-on: https://go-review.googlesource.com/14444Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
Change-Id: I951387f88993715e86b6ab9f18d38ed5c691ee0f Reviewed-on: https://go-review.googlesource.com/14443Reviewed-by:
Minux Ma <minux@golang.org>
-
Yao Zhang authored
MIPS64 has 32 general purpose 64-bit integer registers (R0-R31), 32 64-bit floating point registers (F0-F31). Instructions are fixed-width, and are 32-bit wide. Instructions are all in standard 1-, 2-, 3-operand forms. MIPS64-specific relocations are added. For this reason, test data of cmd/newlink are regenerated. No other changes are made to portable structures. Branch delay slots are current filled with NOP instructions. The function for instruction scheduling (try to fill the delay slot with a useful instruction) is implemented but disabled for now. Change-Id: Ic364999c7a33245260c1381fc26a2fa8972d38b3 Reviewed-on: https://go-review.googlesource.com/14442Reviewed-by:
Minux Ma <minux@golang.org>
-
Matthew Dempsky authored
Change-Id: Ie5f70af7e673bb2c691a45c28db2c017e6cddd4f Reviewed-on: https://go-review.googlesource.com/16833Reviewed-by:
Minux Ma <minux@golang.org>
-
Matthew Dempsky authored
Applies to types fixAlloc, mCache, mCentral, mHeap, mSpan, and mSpanList. Two special cases: 1. mHeap_Scavenge() previously didn't take an *mheap parameter, so it was specially handled in this CL. 2. mHeap_Free() would have collided with mheap's "free" field, so it's been renamed to (*mheap).freeSpan to parallel its underlying (*mheap).freeSpanLocked method. Change-Id: I325938554cca432c166fe9d9d689af2bbd68de4b Reviewed-on: https://go-review.googlesource.com/16221Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
It was disabled because of the lack of external linking. Change-Id: Iccb4a4ef8c57d048d53deabe4e0f4e6b9dccce33 Reviewed-on: https://go-review.googlesource.com/16797Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
If you say "go install -buildmode=shared a b" and package a depends on another package c, package c is implicitly included in the resulting shared library (as specified by "Go Execution Modes"). But if c depends on b, linking against this shared library hangs, because the go tool doesn't know when computing c's dependencies that c is part of the same shared library as c. Fix this by tracking the shared library a package *is* in separately from the shared library a package has been explicitly linked into. Fixes #13044 Change-Id: Iacfedab24ae9731ed53d225678b447a2a888823c Reviewed-on: https://go-review.googlesource.com/16338 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 11 Nov, 2015 18 commits
-
-
Michael Hudson-Doyle authored
I want to use CX as a scratch register in position independent code and these uses are easy to remove. Change-Id: I9e3cb470d7f0000d85786c30bd769d9ec86d532a Reviewed-on: https://go-review.googlesource.com/16382Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
The linker writes the number of file symbols (Nhistfile) to the filetab slice and then Nhistfile offsets -- which means the slice contains Nhistfile+1 entries, not just Nhistfile. I think this bug has been around since at least 1.4 but it's easier to trigger with shared libraries and a tiny binary that only has a couple of functions in it -- try go install -buildmode=shared std && go run -linkshared test/fixedbugs/issue4388.go. Change-Id: I6c0f01f1e607b9b2b96872e37ffce81281911504 Reviewed-on: https://go-review.googlesource.com/16342 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Hyang-Ah Hana Kim authored
Update golang/go#9327. Change-Id: I27ef973190d9ae652411caf3739414b5d46ca7d2 Reviewed-on: https://go-review.googlesource.com/16679Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Hyang-Ah Hana Kim authored
Same ugly hack as https://go-review.googlesource.com/15991. Update golang/go#9327. Change-Id: I58284e83268a15de95eabc833c3e01bf1e3faa2e Reviewed-on: https://go-review.googlesource.com/16678Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Austin Clements authored
The GC now handles the root marking jobs as part of general marking, so work.markfor is no longer used. Change-Id: I6c3b23fed27e4e7ea6430d6ca7ba25ae4d04ed14 Reviewed-on: https://go-review.googlesource.com/16811 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
When we're jumping time forward, it means everyone is asleep, so there should always be an M available. Furthermore, this causes both allocation and write barriers in contexts that may be running without a P (such as in sysmon). Hence, replace this allocation with a throw. Updates #10600. Change-Id: I2cee70d5db828d0044082878995949edb25dda5f Reviewed-on: https://go-review.googlesource.com/16815Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently traceBuf keeps track of where it is in the trace buffer by also maintaining a slice that points in to this buffer with an initial length of 0 and a cap of the length of the array. All writes to this buffer are done by appending to the slice (as long as the bounds checks are right, it will never overflow and the append won't allocate a new slice). Each of these appends generates a write barrier. As long as we never overflow the buffer, this write barrier won't fire, but this wreaks havoc with eliminating write barriers from the tracing code. If we were to overflow the buffer, this would both allocate and invoke a write barrier, both things that are dicey at best to do in many of the contexts tracing happens. It also wastes space in the traceBuf and leads to more complex code and more complex generated code. Replace this slice trick with keeping track of a simple array position. Updates #10600. Change-Id: I0a63eecec1992e195449f414ed47653f66318d0e Reviewed-on: https://go-review.googlesource.com/16814 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Austin Clements authored
This replaces *traceStack with traceStackPtr, much like the preceding commit. Updates #10600. Change-Id: Ifadc35eb37a405ae877f9740151fb31a0ca1d08f Reviewed-on: https://go-review.googlesource.com/16813 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Austin Clements authored
The tracing code is currently called from contexts such as sysmon and the scheduler where write barriers are not allowed. Unfortunately, while the common paths through the tracing code do not have write barriers, many of the less common paths dealing with buffer overflow and recycling do. This change replaces all *traceBufs with traceBufPtrs. In the style of guintptr, etc., the GC does not trace traceBufPtrs and write barriers do not apply when these pointers are written. Since traceBufs are allocated from non-GC'd memory and manually managed, this is always safe. Updates #10600. Change-Id: I52b992d36d1b634ebd855c8cde27947ec14f59ba Reviewed-on: https://go-review.googlesource.com/16812 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Brad Fitzpatrick authored
Mention shallow clones. Fixes #13204 Change-Id: I0ed9d4e829d388425beba0d64e6889d16d4bb173 Reviewed-on: https://go-review.googlesource.com/16822Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Commit 7407d8e5 was rebased over the switch to runtime/internal/atomic and introduced a call to xadd64, which no longer exists. Fix that call. Change-Id: I99c93469794c16504ae4a8ffe3066ac382c66a3a Reviewed-on: https://go-review.googlesource.com/16816Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently, sweeping is performed before allocating a span by charging for the entire size of the span requested, rather than the number of bytes actually available for allocation from the returned span. That is, if the returned span is 8K, but already has 6K in use, the mutator is charged for 8K of heap allocation even though it can only allocate 2K more from the span. As a result, proportional sweep is over-aggressive and tends to finish much earlier than it needs to. This effect is more amplified by fragmented heaps. Fix this by reimbursing the mutator for the used space in a span once it has allocated that span. We still have to charge up-front for the worst-case because we don't know which span the mutator will get, but at least we can correct the over-charge once it has a span, which will go toward later span allocations. This has negligible effect on the throughput of the go1 benchmarks and the garbage benchmark. Fixes #12040. Change-Id: I0e23e7a4ccf126cca000fed5067b20017028dd6b Reviewed-on: https://go-review.googlesource.com/16515Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Meng Zhuo authored
Currently go get will clone the full history of git repos. We can improve the download waiting time/size by passing depth argument. The docs about shallow clones and the --depth argument are here: https://git-scm.com/docs/git-clone https://git-scm.com/docs/git-pull Fixes #13078 Change-Id: Ie891d905d9c77f6ecadf7dcd5b44b477f4e079e0 Reviewed-on: https://go-review.googlesource.com/16360Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
The runtime is not instrumented, but the calls to msanread in the runtime can sometimes refer to the system stack. An example is the call to copy in stkbucket in mprof.go. Depending on what C code has done, the system stack may appear uninitialized to msan. Change-Id: Ic21705b9ac504ae5cf7601a59189302f072e7db1 Reviewed-on: https://go-review.googlesource.com/16660Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Ian Lance Taylor authored
This is a fix for the -msan option when using cgo callbacks. A cgo callback works by writing out C code that puts a struct on the stack and passes the address of that struct into Go. The result parameters are fields of the struct. The Go code will write to the result parameters, but the Go code thinks it is just writing into the Go stack, and therefore won't call msanwrite. This CL adds a call to msanwrite in the cgo callback code so that the C knows that results were written. Change-Id: I80438dbd4561502bdee97fad3f02893a06880ee1 Reviewed-on: https://go-review.googlesource.com/16611Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Austin Clements authored
This changes "mark worker (idle)" to "GC worker (idle)" so it's more clear to users that these goroutines are GC-related. It changes "GC assist" to "GC assist wait" to make it clear that the assist is blocked. Change-Id: Iafbc0903c84f9250ff6bee14baac6fcd4ed5ef76 Reviewed-on: https://go-review.googlesource.com/16511Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
We couldn't do this before this point because it must be done before the next GC cycle starts. Hence, if it delayed the start of the next cycle, that would widen the window between reaching the heap trigger of the next cycle and starting the next GC cycle, during which the mutator could over-allocate. With the decentralized GC, any mutators that reach the heap trigger will block on the GC starting, so it's safe to widen the time between starting the world and being able to start the next GC cycle. Fixes #11465. Change-Id: Ic7ea7e9eba5b66fc050299f843a9c9001ad814aa Reviewed-on: https://go-review.googlesource.com/16394Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
When using gccgo it's OK if a pointer passed to C remains on the stack. Gccgo does not have the clear distinction between C and Go stacks. Change-Id: I3af9dd6fe078214ab16d9d8dad2d206608d7891d Reviewed-on: https://go-review.googlesource.com/16774 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-