- 13 May, 2015 4 commits
-
-
Rick Hudson authored
One important use case is a pipeline computation that pass values from one Goroutine to the next and then exits or is placed in a wait state. If GOMAXPROCS > 1 a Goroutine running on P1 will enable another Goroutine and then immediately make P1 available to execute it. We need to prevent other Ps from stealing the G that P1 is about to execute. Otherwise the Gs can thrash between Ps causing unneeded synchronization and slowing down throughput. Fix this by changing the stealing logic so that when a P attempts to steal the only G on some other P's run queue, it will pause momentarily to allow the victim P to schedule the G. As part of optimizing stealing we also use a per P victim queue move stolen gs. This eliminates the zeroing of a stack local victim queue which turned out to be expensive. This CL is a necessary but not sufficient prerequisite to changing the default value of GOMAXPROCS to something > 1 which is another CL/discussion. For highly serialized programs, such as GoroutineRing below this can make a large difference. For larger and more parallel programs such as the x/benchmarks there is no noticeable detriment. ~/work/code/src/rsc.io/benchstat/benchstat old.txt new.txt name old mean new mean delta GoroutineRing 30.2µs × (0.98,1.01) 30.1µs × (0.97,1.04) ~ (p=0.941) GoroutineRing-2 113µs × (0.91,1.07) 30µs × (0.98,1.03) -73.17% (p=0.004) GoroutineRing-4 144µs × (0.98,1.02) 32µs × (0.98,1.01) -77.69% (p=0.000) GoroutineRingBuf 32.7µs × (0.97,1.03) 32.5µs × (0.97,1.02) ~ (p=0.795) GoroutineRingBuf-2 120µs × (0.92,1.08) 33µs × (1.00,1.00) -72.48% (p=0.004) GoroutineRingBuf-4 138µs × (0.92,1.06) 33µs × (1.00,1.00) -76.21% (p=0.003) The bench benchmarks show little impact. old new garbage 7032879 7011696 httpold 25509 25301 splayold 1022073 1019499 jsonold 28230624 28081433 Change-Id: I228c48fed8d85c9bbef16a7edc53ab7898506f50 Reviewed-on: https://go-review.googlesource.com/9872Reviewed-by:
Austin Clements <austin@google.com>
-
Mikio Hara authored
Fixes #10787. Change-Id: I35c96808a713dafb1f0fea301fa3f3528fe6a5bf Reviewed-on: https://go-review.googlesource.com/9948Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
Mikio Hara authored
FileConn and FilePacketConn APIs accept user-configured socket descriptors to make them work together with runtime-integrated network poller, but there's a limitation. The APIs reject protocol sockets that are not supported by standard library. It's very hard for the net, syscall packages to look after all platform, feature-specific sockets. This change allows various platform, feature-specific socket descriptors to use runtime-integrated network poller by using SocketConn, SocketPacketConn APIs that bridge between the net, syscall packages and platforms. New exposed APIs: pkg net, func SocketConn(*os.File, SocketAddr) (Conn, error) pkg net, func SocketPacketConn(*os.File, SocketAddr) (PacketConn, error) pkg net, type SocketAddr interface { Addr, Raw } pkg net, type SocketAddr interface, Addr([]uint8) Addr pkg net, type SocketAddr interface, Raw(Addr) []uint8 Fixes #10565. Change-Id: Iec57499b3d84bb5cb0bcf3f664330c535eec11e3 Reviewed-on: https://go-review.googlesource.com/9275Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
If __LP64__ is defined then the type "long" is 64-bits, and there is no need to explicitly request _FILE_OFFSET_BITS == 64. This changes the definitions of F_GETLK, F_SETLK, and F_SETLKW on PPC to the values that the kernel requires. The values used in C when _FILE_OFFSET_BITS == 64 are corrected by the glibc fcntl function before making the system call. With this change, regenerate ppc64le files on Ubuntu trusty. Change-Id: I8dddbd8a6bae877efff818f5c5dd06291ade3238 Reviewed-on: https://go-review.googlesource.com/9962Reviewed-by:
Minux Ma <minux@golang.org>
-
- 12 May, 2015 19 commits
-
-
Hyang-Ah (Hana) Kim authored
On android the generated header files are located in pkg/$(go env GOOS)_$(go env GOARCH)_testcshared. The test was broken since https://go-review.googlesource.com/9798. The installation path differs based on codegenArgs (around src/cmd/go/build.go line 389), and the codegenArgs is platform dependent. Change-Id: I01ae9cb957fb7676e399f3b8c067f24c5bd20b9d Reviewed-on: https://go-review.googlesource.com/9980Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
Fixes #10794. Change-Id: Id91485394ddbadc28c800e1d0c3ec281ba6cd098 Reviewed-on: https://go-review.googlesource.com/9990Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
This will skip system call numbers that are ifdef'ed out in unistd.h, as occurs on PPC. Change-Id: I88e640e4621c7a8cc266433f34a7b4be71543ec9 Reviewed-on: https://go-review.googlesource.com/9966Reviewed-by:
Minux Ma <minux@golang.org>
-
Austin Clements authored
Running these tests on the system stack is problematic because they allocate Ps, which are large enough to overflow the system stack if they are stack-allocated. It used to be necessary to run these tests on the system stack because they were written in C, but since this is no longer the case, we can fix this problem by simply not running the tests on the system stack. This also means we no longer need the hack in one of these tests that forces the allocated Ps to escape to the heap, so eliminate that as well. Change-Id: I9064f5f8fd7f7b446ff39a22a70b172cfcb2dc57 Reviewed-on: https://go-review.googlesource.com/9923Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com>
-
Russ Cox authored
The line in cgen.go was lost during the ginscmp CL. The ggen.go change is not strictly necessary, but it makes the 5g -S output for x[0] match what it said before the ginscmp CL. Change-Id: I5890a9ec1ac69a38509416eda5aea13b8b12b94a Reviewed-on: https://go-review.googlesource.com/9929Reviewed-by:
Russ Cox <rsc@golang.org>
-
Andrew Williams authored
Fix bug on Linux SysProcAttr handling: setting both Pdeathsig and Credential caused Pdeathsig to be ignored. This is because the kernel clears the deathsignal field when performing a setuid/setgid system call. Avoid this by moving Pdeathsig handling after Credential handling. Fixes #9686 Change-Id: Id01896ad4e979b8c448e0061f00aa8762ca0ac94 Reviewed-on: https://go-review.googlesource.com/3290Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
The code generated for x = append(x, v) is roughly: t := x if len(t)+1 > cap(t) { t = grow(t) } t[len(t)] = v len(t)++ x = t We used to generate this code as Go pseudocode during walk. Generate it instead as actual instructions during gen. Doing so lets us apply a few optimizations. The most important is that when, as in the above example, the source slice and the destination slice are the same, the code can instead do: t := x if len(t)+1 > cap(t) { t = grow(t) x = {base(t), len(t)+1, cap(t)} } else { len(x)++ } t[len(t)] = v That is, in the fast path that does not reallocate the array, only the updated length needs to be written back to x, not the array pointer and not the capacity. This is more like what you'd write by hand in C. It's faster in general, since the fast path elides two of the three stores, but it's especially faster when the form of x is such that the base pointer write would turn into a write barrier. No write, no barrier. name old mean new mean delta BinaryTree17 5.68s × (0.97,1.04) 5.81s × (0.98,1.03) +2.35% (p=0.023) Fannkuch11 4.41s × (0.98,1.03) 4.35s × (1.00,1.00) ~ (p=0.090) FmtFprintfEmpty 92.7ns × (0.91,1.16) 86.0ns × (0.94,1.11) -7.31% (p=0.038) FmtFprintfString 281ns × (0.96,1.08) 276ns × (0.98,1.04) ~ (p=0.219) FmtFprintfInt 288ns × (0.97,1.06) 274ns × (0.98,1.06) -4.94% (p=0.002) FmtFprintfIntInt 493ns × (0.97,1.04) 506ns × (0.99,1.01) +2.65% (p=0.009) FmtFprintfPrefixedInt 423ns × (0.97,1.04) 391ns × (0.99,1.01) -7.52% (p=0.000) FmtFprintfFloat 598ns × (0.99,1.01) 566ns × (0.99,1.01) -5.27% (p=0.000) FmtManyArgs 1.89µs × (0.98,1.05) 1.91µs × (0.99,1.01) ~ (p=0.231) GobDecode 14.8ms × (0.98,1.03) 15.3ms × (0.99,1.02) +3.01% (p=0.000) GobEncode 12.3ms × (0.98,1.01) 11.5ms × (0.97,1.03) -5.93% (p=0.000) Gzip 656ms × (0.99,1.05) 645ms × (0.99,1.01) ~ (p=0.055) Gunzip 142ms × (1.00,1.00) 142ms × (1.00,1.00) -0.32% (p=0.034) HTTPClientServer 91.2µs × (0.97,1.04) 90.5µs × (0.97,1.04) ~ (p=0.468) JSONEncode 32.6ms × (0.97,1.08) 32.0ms × (0.98,1.03) ~ (p=0.190) JSONDecode 114ms × (0.97,1.05) 114ms × (0.99,1.01) ~ (p=0.887) Mandelbrot200 6.11ms × (0.98,1.04) 6.04ms × (1.00,1.01) ~ (p=0.167) GoParse 6.66ms × (0.97,1.04) 6.47ms × (0.97,1.05) -2.81% (p=0.014) RegexpMatchEasy0_32 159ns × (0.99,1.00) 171ns × (0.93,1.07) +7.19% (p=0.002) RegexpMatchEasy0_1K 538ns × (1.00,1.01) 550ns × (0.98,1.01) +2.30% (p=0.000) RegexpMatchEasy1_32 138ns × (1.00,1.00) 135ns × (0.99,1.02) -1.60% (p=0.000) RegexpMatchEasy1_1K 869ns × (0.99,1.01) 879ns × (1.00,1.01) +1.08% (p=0.000) RegexpMatchMedium_32 252ns × (0.99,1.01) 243ns × (1.00,1.00) -3.71% (p=0.000) RegexpMatchMedium_1K 72.7µs × (1.00,1.00) 70.3µs × (1.00,1.00) -3.34% (p=0.000) RegexpMatchHard_32 3.85µs × (1.00,1.00) 3.82µs × (1.00,1.01) -0.81% (p=0.000) RegexpMatchHard_1K 118µs × (1.00,1.00) 117µs × (1.00,1.00) -0.56% (p=0.000) Revcomp 920ms × (0.97,1.07) 917ms × (0.97,1.04) ~ (p=0.808) Template 129ms × (0.98,1.03) 114ms × (0.99,1.01) -12.06% (p=0.000) TimeParse 619ns × (0.99,1.01) 622ns × (0.99,1.01) ~ (p=0.062) TimeFormat 661ns × (0.98,1.04) 665ns × (0.99,1.01) ~ (p=0.524) See next CL for combination with a similar optimization for slice. The benchmarks that are slower in this CL are still faster overall with the combination of the two. Change-Id: I2a7421658091b2488c64741b4db15ab6c3b4cb7e Reviewed-on: https://go-review.googlesource.com/9812Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
This lets us abstract away which arguments can be constants and so on and lets the back ends reverse the order of arguments if that helps. Change-Id: I283ec1d694f2dd84eba22e5eb4aad78a2d2d9eb0 Reviewed-on: https://go-review.googlesource.com/9810Reviewed-by:
David Chase <drchase@google.com>
-
Rob Pike authored
Messages that are too big are rejected when read, so they should be rejected when written too. Fixes #10518. Change-Id: I96678fbe2d94f51b957fe26faef33cd8df3823dd Reviewed-on: https://go-review.googlesource.com/9965Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
The status buffer built by the exit function was not nil-terminated. Fixes #10789. Change-Id: I2d34ac50a19d138176c4b47393497ba7070d5b61 Reviewed-on: https://go-review.googlesource.com/9953Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
Once added to the signal queue, the pointer passed to the signal handler could no longer be valid. Instead of passing the pointer to the note string, we recopy the value of the note string to a static array in the signal queue. Fixes #10784. Change-Id: Iddd6837b58a14dfaa16b069308ae28a7b8e0965b Reviewed-on: https://go-review.googlesource.com/9950Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
This slows down more things than I expected, but it also speeds things up, and it reduces stack frame sizes and the load on the optimizer, so it's still likely a net win. name old mean new mean delta BenchmarkBinaryTree17 13.2s × (0.98,1.03) 13.2s × (0.98,1.02) ~ (p=0.795) BenchmarkFannkuch11 4.41s × (1.00,1.00) 4.45s × (0.99,1.01) +0.88% (p=0.000) BenchmarkFmtFprintfEmpty 86.4ns × (0.99,1.01) 90.1ns × (0.95,1.05) +4.31% (p=0.000) BenchmarkFmtFprintfString 318ns × (0.96,1.07) 337ns × (0.98,1.03) +6.05% (p=0.000) BenchmarkFmtFprintfInt 332ns × (0.97,1.04) 320ns × (0.97,1.02) -3.42% (p=0.000) BenchmarkFmtFprintfIntInt 562ns × (0.96,1.04) 574ns × (0.96,1.06) +2.00% (p=0.013) BenchmarkFmtFprintfPrefixedInt 442ns × (0.96,1.06) 450ns × (0.97,1.05) +1.73% (p=0.039) BenchmarkFmtFprintfFloat 640ns × (0.99,1.02) 659ns × (0.99,1.03) +3.01% (p=0.000) BenchmarkFmtManyArgs 2.19µs × (0.97,1.06) 2.21µs × (0.98,1.02) ~ (p=0.104) BenchmarkGobDecode 20.0ms × (0.98,1.03) 19.7ms × (0.97,1.04) -1.35% (p=0.035) BenchmarkGobEncode 17.8ms × (0.96,1.04) 18.0ms × (0.96,1.06) ~ (p=0.131) BenchmarkGzip 653ms × (0.99,1.02) 652ms × (0.99,1.01) ~ (p=0.572) BenchmarkGunzip 143ms × (0.99,1.02) 142ms × (1.00,1.01) -0.52% (p=0.005) BenchmarkHTTPClientServer 110µs × (0.98,1.03) 108µs × (0.99,1.02) -1.90% (p=0.000) BenchmarkJSONEncode 40.0ms × (0.98,1.05) 41.5ms × (0.97,1.06) +3.89% (p=0.000) BenchmarkJSONDecode 118ms × (0.99,1.01) 118ms × (0.98,1.01) +0.69% (p=0.010) BenchmarkMandelbrot200 6.03ms × (1.00,1.01) 6.03ms × (1.00,1.01) ~ (p=0.924) BenchmarkGoParse 8.43ms × (0.92,1.11) 8.56ms × (0.93,1.05) ~ (p=0.242) BenchmarkRegexpMatchEasy0_32 180ns × (0.91,1.07) 163ns × (1.00,1.00) -9.33% (p=0.000) BenchmarkRegexpMatchEasy0_1K 550ns × (0.98,1.02) 558ns × (0.99,1.01) +1.44% (p=0.000) BenchmarkRegexpMatchEasy1_32 152ns × (0.94,1.05) 139ns × (0.98,1.02) -8.51% (p=0.000) BenchmarkRegexpMatchEasy1_1K 909ns × (0.98,1.06) 868ns × (0.99,1.02) -4.52% (p=0.000) BenchmarkRegexpMatchMedium_32 262ns × (0.97,1.03) 253ns × (0.99,1.02) -3.31% (p=0.000) BenchmarkRegexpMatchMedium_1K 73.8µs × (0.98,1.04) 72.7µs × (1.00,1.01) -1.61% (p=0.001) BenchmarkRegexpMatchHard_32 3.87µs × (0.99,1.02) 3.87µs × (1.00,1.01) ~ (p=0.791) BenchmarkRegexpMatchHard_1K 118µs × (0.98,1.04) 117µs × (0.99,1.02) ~ (p=0.110) BenchmarkRevcomp 1.00s × (0.94,1.10) 0.99s × (0.94,1.09) ~ (p=0.433) BenchmarkTemplate 140ms × (0.97,1.04) 140ms × (0.99,1.01) ~ (p=0.303) BenchmarkTimeParse 622ns × (0.99,1.02) 625ns × (0.99,1.01) +0.51% (p=0.001) BenchmarkTimeFormat 731ns × (0.98,1.04) 719ns × (0.99,1.01) -1.66% (p=0.000) Change-Id: Ibc3edb59a178adafda50156f46a341f69a17d83f Reviewed-on: https://go-review.googlesource.com/9721Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
Today's earlier fix can stay, but it's a band-aid over the real problem, which is that bad code was slipping through the type checker into the back end (and luckily causing a type error there). I discovered this because my new append does not use the same temporaries and failed the test as written. Fixes #9521. Change-Id: I7e33e2ea15743406e15c6f3fdf73e1edecda69bd Reviewed-on: https://go-review.googlesource.com/9921Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Jens Frederich authored
Any Git branch can be the default branch not only master. Removing hardwired 'checkout master', and using 'checkout {tag}' is the best choice. It works with and without a master branch. Furthermore it resolves the Github default branch issue. Changing Github default branch is effectively changing HEAD. Fixes #9032 Change-Id: I19a1221bcefe0806e7556c124c6da7ac0c2160b5 Reviewed-on: https://go-review.googlesource.com/5312Reviewed-by:
Russ Cox <rsc@golang.org>
-
Patrick Mezard authored
registry.ReadSubKeyNames requires QUERY access right in addition to ENUMERATE_SUB_KEYS. This was making TestLocalZoneAbbr fail on Windows 7 in Paris/Madrid timezone. It succeeded on Windows 8 because timezone name changed from "Paris/Madrid" to "Romance Standard Time", the latter being matched by an abbrs entry. Change-Id: I791287ba9d1b3556246fa4e9e1604a1fbba1f5e6 Reviewed-on: https://go-review.googlesource.com/9809Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alex Brainman authored
TestAcceptIgnoreSomeErrors was created to test that network accept function ignores some errors. But conditions created by the test also affects network reads. Change the test to ignore these read errors when acceptable. Fixes #10785 Change-Id: I3da85cb55bd3e78c1980ad949e53e82391f9b41e Reviewed-on: https://go-review.googlesource.com/9942Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Shenghou Ma authored
Change-Id: I58c6e914d0e977d5748c87d277e30c933ed86f99 Reviewed-on: https://go-review.googlesource.com/9924Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
This: 1) Defines the ABI hash of a package (as the SHA1 of the __.PKGDEF) 2) Defines the ABI hash of a shared library (sort the packages by import path, concatenate the hashes of the packages and SHA1 that) 3) When building a shared library, compute the above value and define a global symbol that points to a go string that has the hash as its value. 4) When linking against a shared library, read the abi hash from the library and put both the value seen at link time and a reference to the global symbol into the moduledata. 5) During runtime initialization, check that the hash seen at link time still matches the hash the global symbol points to. Change-Id: Iaa54c783790e6dde3057a2feadc35473d49614a5 Reviewed-on: https://go-review.googlesource.com/8773Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Michael Hudson-Doyle authored
addmoduledata is called from a .init_array function and need to follow the platform ABI. It contains accesses to global data which are rewritten to use R15 by the assembler, and as R15 is callee-save we need to save it. Change-Id: I03893efb1576aed4f102f2465421f256f3bb0f30 Reviewed-on: https://go-review.googlesource.com/9941Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 11 May, 2015 17 commits
-
-
Mikio Hara authored
Change-Id: I9b058472f5b4943db6e6f1c1243411ce61624c18 Reviewed-on: https://go-review.googlesource.com/9916Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Rahul Chaudhry authored
Change-Id: I89778988baec1cf4a35d9342c7dbe8c4c08ff3cd Reviewed-on: https://go-review.googlesource.com/9893 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Alan Donovan authored
Change-Id: I4b1ce33253890de9bc64fee9b476fe52eec87fc0 Reviewed-on: https://go-review.googlesource.com/9920Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Alexandre Cesaro authored
Fixes #4943 Fixes #4687 Fixes #7079 Change-Id: Ia96f07d650a3af935cd75fd7e3253f4af2977429 Reviewed-on: https://go-review.googlesource.com/7890Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Rob Pike authored
Fixes #10770. Fixes #10771. This time maybe for sure? Change-Id: I43d6e5fd6846cf58427fec183832d500a932df59 Reviewed-on: https://go-review.googlesource.com/9896Reviewed-by:
Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
Fixes #10778. Change-Id: I09aab55dec429ec4a023e5ad591b929563cef0d9 Reviewed-on: https://go-review.googlesource.com/9855Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Didier Spezia authored
Instead of errors like: ./blank2.go:15: cannot use ~b1 (type []int) as type int in assignment we now have: ./blank2.go:15: cannot use _ (type []int) as type int in assignment Less confusing for users. Fixes #9521 Change-Id: Ieab9859040e8e0df95deeaee7eeb408d3be61c0f Reviewed-on: https://go-review.googlesource.com/9902Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
DWARF generation appears to assume Cpos is cheap and this makes linking godoc about 8% faster and linking the standard library into a single shared library about 22% faster on my machine. Updates #10571 Change-Id: I3f81efd0174e356716e7971c4f59810b72378177 Reviewed-on: https://go-review.googlesource.com/9913Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Morsing authored
When running the client header timeout test, there is a race between us timing out and waiting on the remaining requests to be serviced. If the client times out before the server blocks on the channel in the handler, we will be simultaneously adding to a waitgroup with the value 0 and waiting on it when we call TestServer.Close(). This is largely a theoretical race. We have to time out before we enter the handler and the only reason we would time out if we're blocked on the channel. Nevertheless, make the race detector happy by turning the close into a channel send. This turns the defer call into a synchronization point and we can be sure that we've entered the handler before we close the server. Fixes #10780 Change-Id: Id73b017d1eb7503e446aa51538712ef49f2f5c9e Reviewed-on: https://go-review.googlesource.com/9905Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
The current implementation of typedmemmove walks the ptrmask in the type to find out where pointers are. This led to turning off GC programs for the Go 1.5 dev cycle, so that there would always be a ptrmask. Instead of also interpreting the GC programs, interpret the heap bitmap, which we know must be available and up to date. (There is no point to write barriers when writing outside the heap.) This CL is only about correctness. The next CL will optimize the code. Change-Id: Id1305c7c071fd2734ab96634b0e1c745b23fa793 Reviewed-on: https://go-review.googlesource.com/9886Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
We want typedmemmove to use the heap bitmap to determine where pointers are, instead of reinterpreting the type information. The heap bitmap is simpler to access. In general, typedmemmove will need to be able to look up the bits for any word and find valid pointer information, so fill even after the dead marker. Not filling after the dead marker was an optimization I introduced only a few days ago, when reintroducing the dead marker code. At the time I said it probably wouldn't last, and it didn't. Change-Id: I6ba01bff17ddee1ff429f454abe29867ec60606e Reviewed-on: https://go-review.googlesource.com/9885Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
The runtime deals with 1-bit pointer bitmaps and 2-bit heap bitmaps that have entries for both pointers and mark bits. Each byte in a 1-bit pointer bitmap looks like pppppppp (all pointer bits). Each byte in a 2-bit heap bitmap looks like mpmpmpmp (mark, pointer, ...). This means that when converting from 1-bit to 2-bit, as we do during malloc, we have to pick up 4 bits in pppp form and use shifts to create the mpmpmpmp form. This CL changes the 2-bit heap bitmap form to mmmmpppp, so that 4 bits picked up in 1-bit form can be used directly in the low bits of the heap bitmap byte, without expansion. This simplifies the code, and it also happens to be faster. name old mean new mean delta SetTypePtr 14.0ns × (0.98,1.09) 14.0ns × (0.98,1.08) ~ (p=0.966) SetTypePtr8 16.5ns × (0.99,1.05) 15.3ns × (0.96,1.16) -6.86% (p=0.012) SetTypePtr16 21.3ns × (0.98,1.05) 18.8ns × (0.94,1.14) -11.49% (p=0.000) SetTypePtr32 34.6ns × (0.93,1.22) 27.7ns × (0.91,1.26) -20.08% (p=0.001) SetTypePtr64 55.7ns × (0.97,1.11) 41.6ns × (0.98,1.04) -25.30% (p=0.000) SetTypePtr126 98.0ns × (1.00,1.00) 67.7ns × (0.99,1.05) -30.88% (p=0.000) SetTypePtr128 98.6ns × (1.00,1.01) 68.6ns × (0.99,1.03) -30.44% (p=0.000) SetTypePtrSlice 781ns × (0.99,1.01) 571ns × (0.99,1.04) -26.93% (p=0.000) SetTypeNode1 13.1ns × (0.99,1.01) 12.1ns × (0.99,1.01) -7.45% (p=0.000) SetTypeNode1Slice 113ns × (0.99,1.01) 94ns × (1.00,1.00) -16.35% (p=0.000) SetTypeNode8 32.7ns × (1.00,1.00) 29.8ns × (0.99,1.01) -8.97% (p=0.000) SetTypeNode8Slice 266ns × (1.00,1.00) 204ns × (1.00,1.00) -23.40% (p=0.000) SetTypeNode64 58.0ns × (0.98,1.08) 42.8ns × (1.00,1.01) -26.24% (p=0.000) SetTypeNode64Slice 1.55µs × (0.99,1.02) 0.96µs × (1.00,1.00) -37.84% (p=0.000) SetTypeNode64Dead 13.1ns × (0.99,1.01) 12.1ns × (1.00,1.00) -7.33% (p=0.000) SetTypeNode64DeadSlice 1.52µs × (1.00,1.01) 1.08µs × (1.00,1.01) -28.95% (p=0.000) SetTypeNode124 97.9ns × (1.00,1.00) 67.1ns × (1.00,1.01) -31.49% (p=0.000) SetTypeNode124Slice 2.87µs × (0.99,1.02) 1.75µs × (1.00,1.01) -39.15% (p=0.000) SetTypeNode126 98.4ns × (1.00,1.01) 68.1ns × (1.00,1.01) -30.79% (p=0.000) SetTypeNode126Slice 2.91µs × (0.99,1.01) 1.77µs × (0.99,1.01) -39.09% (p=0.000) SetTypeNode1024 732ns × (1.00,1.00) 511ns × (0.87,1.42) -30.14% (p=0.000) SetTypeNode1024Slice 23.1µs × (1.00,1.00) 13.9µs × (0.99,1.02) -39.83% (p=0.000) Change-Id: I12e3b850a4e6fa6c8146b8635ff728f3ef658819 Reviewed-on: https://go-review.googlesource.com/9828Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Moving them up makes them properly aligned on 32-bit systems. There are some odd fields above them right now (like fixalloc and mutex maybe). Change-Id: I57851a5bbb2e7cc339712f004f99bb6c0cce0ca5 Reviewed-on: https://go-review.googlesource.com/9889Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
Most of the calls to panicindex are already marked as not returning, but these two were missed at some point. Performance changes below. name old mean new mean delta BinaryTree17 5.70s × (0.98,1.04) 5.68s × (0.97,1.04) ~ (p=0.681) Fannkuch11 4.32s × (1.00,1.00) 4.41s × (0.98,1.03) +1.98% (p=0.018) FmtFprintfEmpty 92.6ns × (0.91,1.11) 92.7ns × (0.91,1.16) ~ (p=0.969) FmtFprintfString 280ns × (0.97,1.05) 281ns × (0.96,1.08) ~ (p=0.860) FmtFprintfInt 284ns × (0.99,1.02) 288ns × (0.97,1.06) ~ (p=0.207) FmtFprintfIntInt 488ns × (0.98,1.01) 493ns × (0.97,1.04) ~ (p=0.271) FmtFprintfPrefixedInt 418ns × (0.98,1.04) 423ns × (0.97,1.04) ~ (p=0.311) FmtFprintfFloat 597ns × (1.00,1.00) 598ns × (0.99,1.01) ~ (p=0.789) FmtManyArgs 1.87µs × (0.99,1.01) 1.89µs × (0.98,1.05) ~ (p=0.158) GobDecode 14.6ms × (0.99,1.01) 14.8ms × (0.98,1.03) +1.51% (p=0.015) GobEncode 12.3ms × (0.98,1.03) 12.3ms × (0.98,1.01) ~ (p=0.474) Gzip 647ms × (1.00,1.01) 656ms × (0.99,1.05) ~ (p=0.104) Gunzip 142ms × (1.00,1.00) 142ms × (1.00,1.00) ~ (p=0.110) HTTPClientServer 89.6µs × (0.99,1.03) 91.2µs × (0.97,1.04) ~ (p=0.061) JSONEncode 31.7ms × (0.99,1.01) 32.6ms × (0.97,1.08) +2.87% (p=0.038) JSONDecode 111ms × (1.00,1.01) 114ms × (0.97,1.05) +2.47% (p=0.040) Mandelbrot200 6.01ms × (1.00,1.00) 6.11ms × (0.98,1.04) ~ (p=0.073) GoParse 6.54ms × (0.99,1.02) 6.66ms × (0.97,1.04) ~ (p=0.064) RegexpMatchEasy0_32 159ns × (0.99,1.02) 159ns × (0.99,1.00) ~ (p=0.693) RegexpMatchEasy0_1K 540ns × (0.99,1.03) 538ns × (1.00,1.01) ~ (p=0.360) RegexpMatchEasy1_32 137ns × (0.99,1.01) 138ns × (1.00,1.00) ~ (p=0.511) RegexpMatchEasy1_1K 867ns × (1.00,1.01) 869ns × (0.99,1.01) ~ (p=0.193) RegexpMatchMedium_32 252ns × (1.00,1.00) 252ns × (0.99,1.01) ~ (p=0.076) RegexpMatchMedium_1K 72.7µs × (1.00,1.00) 72.7µs × (1.00,1.00) ~ (p=0.963) RegexpMatchHard_32 3.84µs × (1.00,1.00) 3.85µs × (1.00,1.00) ~ (p=0.371) RegexpMatchHard_1K 117µs × (1.00,1.01) 118µs × (1.00,1.00) ~ (p=0.898) Revcomp 909ms × (0.98,1.03) 920ms × (0.97,1.07) ~ (p=0.368) Template 128ms × (0.99,1.01) 129ms × (0.98,1.03) +1.41% (p=0.042) TimeParse 619ns × (0.98,1.01) 619ns × (0.99,1.01) ~ (p=0.730) TimeFormat 651ns × (1.00,1.01) 661ns × (0.98,1.04) ~ (p=0.097) Change-Id: I0ec5baff41f5d282307137ce0d927e6301e4fa10 Reviewed-on: https://go-review.googlesource.com/9811Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
Dead code. This field is left over from Go 1.4, when we elided the fake write barrier in this case. Today, it's unused (always false). The upcoming append/slice changes handle this case again, but without needing this field. Change-Id: Ic6f160b64efdc1bbed02097ee03050f8cd0ab1b8 Reviewed-on: https://go-review.googlesource.com/9789Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
If you are using -h to get a stack trace at the site of the failure, Yyerror will never return. Dump the register allocation sites before calling Yyerror. Change-Id: I51266c03e06cb5084c2eaa89b367b9ed85ba286a Reviewed-on: https://go-review.googlesource.com/9788Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Russ Cox authored
The new(uint64) was moving to the stack, which may not be aligned. Change-Id: Iad070964202001b52029494d43e299fed980f939 Reviewed-on: https://go-review.googlesource.com/9787Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-