- 13 Apr, 2017 23 commits
-
-
Austin Clements authored
This extends the sweeper to free workbufs back to the heap between GC cycles, allowing this memory to be reused for GC'd allocations or eventually returned to the OS. This helps for applications that have high peak heap usage relative to their regular heap usage (for example, a high-memory initialization phase). Workbuf memory is roughly proportional to heap size and since we currently never free workbufs, it's proportional to *peak* heap size. By freeing workbufs, we can release and reuse this memory for other purposes when the heap shrinks. This is somewhat complicated because this costs ~1–2 µs per workbuf span, so for large heaps it's too expensive to just do synchronously after mark termination between starting the world and dropping the worldsema. Hence, we do it asynchronously in the sweeper. This adds a list of "free" workbuf spans that can be returned to the heap. GC moves all workbuf spans to this list after mark termination and the background sweeper drains this list back to the heap. If the sweeper doesn't finish, that's fine, since getempty can directly reuse any remaining spans to allocate more workbufs. Performance impact is negligible. On the x/benchmarks, this reduces GC-bytes-from-system by 6–11%. Fixes #19325. Change-Id: Icb92da2196f0c39ee984faf92d52f29fd9ded7a8 Reviewed-on: https://go-review.googlesource.com/38582 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently the runtime allocates workbufs from persistent memory, which means they can never be freed. Switch to allocating them from manually-managed heap spans. This doesn't free them yet, but it puts us in a position to do so. For #19325. Change-Id: I94b2512a2f2bbbb456cd9347761b9412e80d2da9 Reviewed-on: https://go-review.googlesource.com/38581 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This introduces a new type, *gcBits, to use for alloc/mark bitmap allocations instead of *uint8. This type is marked go:notinheap, so uses of it correctly eliminate write barriers. Since we now have a type, this also extracts some common operations to methods both for convenience and to avoid (*uint8) casts at most use sites. For #19325. Change-Id: Id51f734fb2e96b8b7715caa348c8dcd4aef0696a Reviewed-on: https://go-review.googlesource.com/38580 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This clarifies that the gcBits type is actually an arena of gcBits and will let us introduce a new gcBits type representing a single mark/alloc bitmap allocated from the arena. For #19325. Change-Id: Idedf76d202d9174a17c61bcca9d5539e042e2445 Reviewed-on: https://go-review.googlesource.com/38579 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently, manually-managed spans are included in memstats.heap_inuse and memstats.heap_sys, but when we export these stats to the user, we subtract out how much has been allocated for stack spans from both. This works for now because stacks are the only manually-managed spans we have. However, we're about to use manually-managed spans for more things that don't necessarily have obvious stats we can use to adjust the user-presented numbers. Prepare for this by changing the accounting so manually-managed spans don't count toward heap_inuse or heap_sys. This makes these fields align with the fields presented to the user and means we don't have to track more statistics just so we can adjust these statistics. For #19325. Change-Id: I5cb35527fd65587ff23339276ba2c3969e2ad98f Reviewed-on: https://go-review.googlesource.com/38577 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Austin Clements authored
We're going to start using manually-managed spans for GC workbufs, so rename the allocate/free methods and pass in a pointer to the stats to use instead of using the stack stats directly. For #19325. Change-Id: I37df0147ae5a8e1f3cb37d59c8e57a1fcc6f2980 Reviewed-on: https://go-review.googlesource.com/38576 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Austin Clements authored
We're going to use this free list for other types of manually-managed memory in the heap. For #19325. Change-Id: Ib7e682295133eabfddf3a84f44db43d937bfdd9c Reviewed-on: https://go-review.googlesource.com/38575 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
We're about to generalize _MSpanStack to be used for other forms of in-heap manual memory management in the runtime. This is an automated rename of _MSpanStack to _MSpanManual plus some comment fix-ups. For #19325. Change-Id: I1e20a57bb3b87a0d324382f92a3e294ffc767395 Reviewed-on: https://go-review.googlesource.com/38574 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This avoids needing a mutex to protect stringsym, and preserves a consistent ctxt.Data ordering in the face of a concurrent backend. Updates #15756 Change-Id: I775daae11db5db1269533a00f5249e3a03086ffc Reviewed-on: https://go-review.googlesource.com/40509 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For #19903. Change-Id: Ib28d08d45bfad653bcc1446f160b7b4a485529af Reviewed-on: https://go-review.googlesource.com/40393Reviewed-by:
Rob Pike <r@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Alberto Donizetti authored
Change-Id: I0b1ae9d296115000fb30aab39f9eac1200ae68d0 Reviewed-on: https://go-review.googlesource.com/40451Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Follow-up to review feedback from mdempsky on CL 40507. Reduces mutex contention by about 1%. Change-Id: I540ea6772925f4a59e58f55a3458eff15880c328 Reviewed-on: https://go-review.googlesource.com/40575 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
Extract a helper function, linksymname. This simplifies Linksym, and linksymname will be useful in future work. Change-Id: Ic5ff8b704a16d5020f6931e008e2f630f687cbd3 Reviewed-on: https://go-review.googlesource.com/40550 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This removes a concurrent access of ctxt.Data. Updates #15756 Change-Id: Id017e90e47e093cd8825907f3853bb3d3bf8280d Reviewed-on: https://go-review.googlesource.com/40507 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
In my experience, this usually happens when vet panics. Dumping all unparseable lines should help diagnosis. Inspired by the trybot failures in CL 40511. Change-Id: Ib73e8c8b2942832589c3cc5d33ef35fdafe9965a Reviewed-on: https://go-review.googlesource.com/40508Reviewed-by:
-
Wei Xiao authored
ARMv8 defines crc32 instruction. Comparing to the original crc32 calculation, this patch makes use of crc32 instructions to do crc32 calculation instead of the multiple lookup table algorithms. ARMv8 provides IEEE and Castagnoli polynomials for crc32 calculation so that the perfomance of these two types of crc32 get significant improved. name old time/op new time/op delta CRC32/poly=IEEE/size=15/align=0-32 117ns ± 0% 38ns ± 0% -67.44% CRC32/poly=IEEE/size=15/align=1-32 117ns ± 0% 38ns ± 0% -67.52% CRC32/poly=IEEE/size=40/align=0-32 129ns ± 0% 41ns ± 0% -68.37% CRC32/poly=IEEE/size=40/align=1-32 129ns ± 0% 41ns ± 0% -68.29% CRC32/poly=IEEE/size=512/align=0-32 828ns ± 0% 246ns ± 0% -70.29% CRC32/poly=IEEE/size=512/align=1-32 828ns ± 0% 132ns ± 0% -84.06% CRC32/poly=IEEE/size=1kB/align=0-32 1.58µs ± 0% 0.46µs ± 0% -70.98% CRC32/poly=IEEE/size=1kB/align=1-32 1.58µs ± 0% 0.46µs ± 0% -70.92% CRC32/poly=IEEE/size=4kB/align=0-32 6.06µs ± 0% 1.74µs ± 0% -71.27% CRC32/poly=IEEE/size=4kB/align=1-32 6.10µs ± 0% 1.74µs ± 0% -71.44% CRC32/poly=IEEE/size=32kB/align=0-32 48.3µs ± 0% 13.7µs ± 0% -71.61% CRC32/poly=IEEE/size=32kB/align=1-32 48.3µs ± 0% 13.7µs ± 0% -71.60% CRC32/poly=Castagnoli/size=15/align=0-32 116ns ± 0% 38ns ± 0% -67.07% CRC32/poly=Castagnoli/size=15/align=1-32 116ns ± 0% 38ns ± 0% -66.90% CRC32/poly=Castagnoli/size=40/align=0-32 127ns ± 0% 40ns ± 0% -68.11% CRC32/poly=Castagnoli/size=40/align=1-32 127ns ± 0% 40ns ± 0% -68.11% CRC32/poly=Castagnoli/size=512/align=0-32 828ns ± 0% 132ns ± 0% -84.06% CRC32/poly=Castagnoli/size=512/align=1-32 827ns ± 0% 132ns ± 0% -84.04% CRC32/poly=Castagnoli/size=1kB/align=0-32 1.59µs ± 0% 0.22µs ± 0% -85.89% CRC32/poly=Castagnoli/size=1kB/align=1-32 1.58µs ± 0% 0.22µs ± 0% -85.79% CRC32/poly=Castagnoli/size=4kB/align=0-32 6.14µs ± 0% 0.77µs ± 0% -87.40% CRC32/poly=Castagnoli/size=4kB/align=1-32 6.06µs ± 0% 0.77µs ± 0% -87.25% CRC32/poly=Castagnoli/size=32kB/align=0-32 48.3µs ± 0% 5.9µs ± 0% -87.71% CRC32/poly=Castagnoli/size=32kB/align=1-32 48.4µs ± 0% 6.0µs ± 0% -87.69% CRC32/poly=Koopman/size=15/align=0-32 104ns ± 0% 104ns ± 0% +0.00% CRC32/poly=Koopman/size=15/align=1-32 104ns ± 0% 104ns ± 0% +0.00% CRC32/poly=Koopman/size=40/align=0-32 235ns ± 0% 235ns ± 0% +0.00% CRC32/poly=Koopman/size=40/align=1-32 235ns ± 0% 235ns ± 0% +0.00% CRC32/poly=Koopman/size=512/align=0-32 2.71µs ± 0% 2.71µs ± 0% -0.07% CRC32/poly=Koopman/size=512/align=1-32 2.71µs ± 0% 2.71µs ± 0% -0.04% CRC32/poly=Koopman/size=1kB/align=0-32 5.40µs ± 0% 5.39µs ± 0% -0.06% CRC32/poly=Koopman/size=1kB/align=1-32 5.40µs ± 0% 5.40µs ± 0% +0.02% CRC32/poly=Koopman/size=4kB/align=0-32 21.5µs ± 0% 21.5µs ± 0% -0.16% CRC32/poly=Koopman/size=4kB/align=1-32 21.5µs ± 0% 21.5µs ± 0% -0.05% CRC32/poly=Koopman/size=32kB/align=0-32 172µs ± 0% 172µs ± 0% -0.07% CRC32/poly=Koopman/size=32kB/align=1-32 172µs ± 0% 172µs ± 0% -0.01% name old speed new speed delta CRC32/poly=IEEE/size=15/align=0-32 128MB/s ± 0% 394MB/s ± 0% +207.95% CRC32/poly=IEEE/size=15/align=1-32 128MB/s ± 0% 394MB/s ± 0% +208.09% CRC32/poly=IEEE/size=40/align=0-32 310MB/s ± 0% 979MB/s ± 0% +216.07% CRC32/poly=IEEE/size=40/align=1-32 310MB/s ± 0% 979MB/s ± 0% +216.16% CRC32/poly=IEEE/size=512/align=0-32 618MB/s ± 0% 2074MB/s ± 0% +235.72% CRC32/poly=IEEE/size=512/align=1-32 618MB/s ± 0% 3852MB/s ± 0% +523.55% CRC32/poly=IEEE/size=1kB/align=0-32 646MB/s ± 0% 2225MB/s ± 0% +244.57% CRC32/poly=IEEE/size=1kB/align=1-32 647MB/s ± 0% 2225MB/s ± 0% +243.87% CRC32/poly=IEEE/size=4kB/align=0-32 676MB/s ± 0% 2352MB/s ± 0% +248.02% CRC32/poly=IEEE/size=4kB/align=1-32 672MB/s ± 0% 2352MB/s ± 0% +250.15% CRC32/poly=IEEE/size=32kB/align=0-32 678MB/s ± 0% 2387MB/s ± 0% +252.17% CRC32/poly=IEEE/size=32kB/align=1-32 678MB/s ± 0% 2388MB/s ± 0% +252.11% CRC32/poly=Castagnoli/size=15/align=0-32 129MB/s ± 0% 393MB/s ± 0% +205.51% CRC32/poly=Castagnoli/size=15/align=1-32 129MB/s ± 0% 390MB/s ± 0% +203.41% CRC32/poly=Castagnoli/size=40/align=0-32 314MB/s ± 0% 988MB/s ± 0% +215.04% CRC32/poly=Castagnoli/size=40/align=1-32 314MB/s ± 0% 987MB/s ± 0% +214.68% CRC32/poly=Castagnoli/size=512/align=0-32 618MB/s ± 0% 3860MB/s ± 0% +524.32% CRC32/poly=Castagnoli/size=512/align=1-32 619MB/s ± 0% 3859MB/s ± 0% +523.66% CRC32/poly=Castagnoli/size=1kB/align=0-32 645MB/s ± 0% 4568MB/s ± 0% +608.56% CRC32/poly=Castagnoli/size=1kB/align=1-32 650MB/s ± 0% 4567MB/s ± 0% +602.94% CRC32/poly=Castagnoli/size=4kB/align=0-32 667MB/s ± 0% 5297MB/s ± 0% +693.81% CRC32/poly=Castagnoli/size=4kB/align=1-32 676MB/s ± 0% 5297MB/s ± 0% +684.00% CRC32/poly=Castagnoli/size=32kB/align=0-32 678MB/s ± 0% 5519MB/s ± 0% +713.83% CRC32/poly=Castagnoli/size=32kB/align=1-32 677MB/s ± 0% 5497MB/s ± 0% +712.04% CRC32/poly=Koopman/size=15/align=0-32 143MB/s ± 0% 144MB/s ± 0% +0.27% CRC32/poly=Koopman/size=15/align=1-32 143MB/s ± 0% 144MB/s ± 0% +0.33% CRC32/poly=Koopman/size=40/align=0-32 169MB/s ± 0% 170MB/s ± 0% +0.12% CRC32/poly=Koopman/size=40/align=1-32 170MB/s ± 0% 170MB/s ± 0% +0.08% CRC32/poly=Koopman/size=512/align=0-32 189MB/s ± 0% 189MB/s ± 0% +0.07% CRC32/poly=Koopman/size=512/align=1-32 189MB/s ± 0% 189MB/s ± 0% +0.04% CRC32/poly=Koopman/size=1kB/align=0-32 190MB/s ± 0% 190MB/s ± 0% +0.05% CRC32/poly=Koopman/size=1kB/align=1-32 190MB/s ± 0% 190MB/s ± 0% -0.01% CRC32/poly=Koopman/size=4kB/align=0-32 190MB/s ± 0% 190MB/s ± 0% +0.15% CRC32/poly=Koopman/size=4kB/align=1-32 190MB/s ± 0% 191MB/s ± 0% +0.05% CRC32/poly=Koopman/size=32kB/align=0-32 191MB/s ± 0% 191MB/s ± 0% +0.06% CRC32/poly=Koopman/size=32kB/align=1-32 191MB/s ± 0% 191MB/s ± 0% +0.02% Also fix a bug of arm64 assembler The optimization is mainly contributed by Fangming.Fang <fangming.fang@arm.com> Change-Id: I900678c2e445d7e8ad9e2a9ab3305d649230905f Reviewed-on: https://go-review.googlesource.com/40074Reviewed-by:
Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Meir Fischer authored
The current interface can't access all environment variables directly or via cgi.RequestFromMap, which only reads variables on its "white list" to be set on the http.Request it returns. If an fcgi variable is not on the "white list" - e.g. REMOTE_USER - the old code has no access to its value. This passes variables in the Request context that aren't used to add data to the Request itself and adds a method that parses those env vars from the Request's context. Fixes #16546 Change-Id: Ibf933a768b677ece1bb93d7bf99a14cef36ec671 Reviewed-on: https://go-review.googlesource.com/40012 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Mikio Hara authored
Also adds missing docs. Change-Id: Ibd8dbe8441bc7a41f01ed2e2033db98e479a5176 Reviewed-on: https://go-review.googlesource.com/40412 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
To preserve reproducible builds, the text entries during compilation will be sorted before being printed. TestAssembly currently assumes that function init comes after all user-defined functions. Remove that assumption. Instead of looking for "TEXT" to tell you where a function ends--which may now yield lots of non-function-code junk--look for a line beginning with non-whitespace. Updates #15756 Change-Id: Ibc82dba6143d769ef4c391afc360e523b1a51348 Reviewed-on: https://go-review.googlesource.com/39853 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
Instead of constructing ctxt.Text in Flushplist, which will be called concurrently, do it in InitTextSym, which must be called serially. This allows us to avoid a mutex for ctxt.Text, and preserves the existing ordering of functions for debug output. Passes toolstash-check. Updates #15756 Change-Id: I6322b4da24f9f0db7ba25e5b1b50e8d3be2deb37 Reviewed-on: https://go-review.googlesource.com/40502 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Speeds up build (the bootstrap phase) by ~6 seconds. Bootstrap goes from ~18 seconds to ~12 seconds. Change-Id: I7e2ec8f5fc668bf6168d90098eaf70390b16e479 Reviewed-on: https://go-review.googlesource.com/40503 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lucas Clemente authored
The 128bit FNV hash will be used e.g. in QUIC. The algorithm is described at https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function Change-Id: I13f3ec39b0e12b7a5008824a6619dff2e708ee81 Reviewed-on: https://go-review.googlesource.com/38356 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Monis Khan authored
The current implementation uses a max of 28 bits when decoding an ObjectIdentifier. This change makes it so that an int64 is used to accumulate up to 35 bits. If the resulting data would not overflow an int32, it is used as an int. Thus up to 31 bits may be used to represent each subidentifier of an ObjectIdentifier. Fixes #19933 Change-Id: I95d74b64b24cdb1339ff13421055bce61c80243c Reviewed-on: https://go-review.googlesource.com/40436Reviewed-by:
Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
-
- 12 Apr, 2017 17 commits
-
-
Hiroshi Ioka authored
https://go-review.googlesource.com/c/39932/ handles relative symlinks. But that change is incomplete. We also have to handle relative symlinks starting with slash too. Fixes #19937 Change-Id: I50dbccbaf270cb48a08fa57e5f450e5da18a7701 Reviewed-on: https://go-review.googlesource.com/40410Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
The initialization of an ATEXT Prog's From.Sym can race with the assemblers in a concurrent compiler. CL 40254 contains an initial, failed attempt to fix that race. This CL takes a different approach: Rather than expose an API to initialize the Prog, expose an API to initialize the Sym. The initialization of the Sym can then be moved earlier in the compiler, avoiding the race. The growth of gc.Func has negligible performance impact; see below. Passes toolstash -cmp. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.8MB ± 0% ~ (p=0.968 n=9+10) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.684 n=10+10) GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.912 n=10+10) SSA 1.25GB ± 0% 1.25GB ± 0% ~ (p=0.481 n=10+10) Flate 25.3MB ± 0% 25.3MB ± 0% ~ (p=0.105 n=10+10) GoParser 31.7MB ± 0% 31.8MB ± 0% +0.09% (p=0.016 n=8+10) Reflect 78.3MB ± 0% 78.2MB ± 0% ~ (p=0.190 n=10+10) Tar 26.5MB ± 0% 26.6MB ± 0% +0.13% (p=0.011 n=10+10) XML 42.4MB ± 0% 42.4MB ± 0% ~ (p=0.971 n=10+10) name old allocs/op new allocs/op delta Template 378k ± 1% 378k ± 0% ~ (p=0.315 n=10+9) Unicode 321k ± 1% 321k ± 0% ~ (p=0.436 n=10+10) GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=0.079 n=10+9) SSA 9.70M ± 0% 9.70M ± 0% -0.04% (p=0.035 n=10+10) Flate 233k ± 1% 234k ± 1% ~ (p=0.529 n=10+10) GoParser 315k ± 0% 316k ± 0% ~ (p=0.095 n=9+10) Reflect 980k ± 0% 980k ± 0% ~ (p=0.436 n=10+10) Tar 249k ± 1% 250k ± 0% ~ (p=0.280 n=10+10) XML 391k ± 1% 391k ± 1% ~ (p=0.481 n=10+10) Change-Id: I3c93033dddd2e1df8cc54a106a6e615d27859e71 Reviewed-on: https://go-review.googlesource.com/40496 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
It's flaky and distracting. I'm not sure what it's testing, either. It hasn't saved us before. Somebody can resurrect it if they have time. Updates #15157 Change-Id: I27bbfe51e09b6259bba0f73d60d03a4d38711951 Reviewed-on: https://go-review.googlesource.com/40498Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Josh Bleecher Snyder authored
Prior to this CL, flags such as NOSPLIT on ATEXT Progs were stored in From3.Offset. Some but not all of those flags were also duplicated into From.Sym.Attribute. This CL migrates all of those flags into From.Sym.Attribute and stops creating a From3. A side-effect of this is that printing an ATEXT Prog can no longer simply dump From3.Offset. That's kind of good, since the raw flag value wasn't very informative anyway, but it did necessitate a bunch of updates to the cmd/asm tests. The reason I'm doing this work now is that avoiding storing flags in both From.Sym and From3.Offset simplifies some other changes to fix the data race first described in CL 40254. This CL almost passes toolstash-check -all. The only changes are in cases where the assembler has decided that a function's flags may be altered, e.g. to make a function with no calls in it NOSPLIT. Prior to this CL, that information was not printed. Sample before: "".Ctz64 t=1 size=63 args=0x10 locals=0x0 0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) TEXT "".Ctz64(SB), $0-16 0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB) Sample after: "".Ctz64 t=1 nosplit size=63 args=0x10 locals=0x0 0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) TEXT "".Ctz64(SB), NOSPLIT, $0-16 0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB) Observe the additional "nosplit" in the first line and the additional "NOSPLIT" in the second line. Updates #15756 Change-Id: I5c59bd8f3bdc7c780361f801d94a261f0aef3d13 Reviewed-on: https://go-review.googlesource.com/40495 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Matthew Dempsky authored
These patterns are the only uses of isArg and isAuto, and they all follow a common pattern too. Extract out so that we can more easily tweak the interface for isArg/isAuto. Passes toolstash -cmp for linux/arm64. Change-Id: I9c509dabdc123c93cb1ad2f34fe8c12a9f313f6d Reviewed-on: https://go-review.googlesource.com/40490 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alberto Donizetti authored
Also adjust truncfltlit to make it more similar to trunccmplxlit, and make it report an error for bad Etypes. Fixes #19947 Change-Id: I6684523e989c2293b8a8e85bd2bfb9c399c5ea36 Reviewed-on: https://go-review.googlesource.com/40453Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Austin Clements authored
Currently, dist allows GOOS and GOARCH to appear as *any* substring in a file name when selecting source files to go into go_bootstrap. This was necessary prior to Go 1.4, where it needed to match names like "windows.c", but now it's gratuitously different from go/build. This led to a bug chase to figure out why "stubs_nonlinux.go" was not being built on non-Linux OSes. Change shouldbuild to require an "_" before the GOOS and GOARCH in a file name. This is still less strict than go/build, but the behavior is much closer. Change-Id: I580e9344a3c40d57c0721d345e911e8b4f141f5d Reviewed-on: https://go-review.googlesource.com/40435 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently CallersFrames expands each PC to a slice of Frames and then iteratively returns those Frames. However, this makes it very difficult to avoid heap allocation: either the Frames slice will be heap allocated, or, if it uses internal scratch space for small slices (as it currently does), the Frames object itself has to be heap allocated. Fix this, at least in the common case, by expanding each PC iteratively. We introduce a new pcExpander type that's responsible for expanding a single PC. This maintains state from one Frame to the next in the same PC. Frames then becomes a wrapper around this responsible for feeding it the next PC when the pcExpander runs out of frames for the current PC. This makes it possible to stack-allocate a Frames object, which will make it possible to use this API for PC expansion from within the runtime itself. Change-Id: I993463945ab574557cf1d6bedbe79ce7e9cbbdcd Reviewed-on: https://go-review.googlesource.com/40434 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Lazar <lazard@golang.org>
-
David du Colombier authored
TestRuntimeTypeDIEs has been added in CL 38350. This test is failing on Plan 9 because executables don't have a DWARF symbol table. Fixes #19944. Change-Id: I121875bfd5f9f02ed668f8fb0686a0edffa2a99d Reviewed-on: https://go-review.googlesource.com/40452 Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I5b692eb0586c40f3735a6b9c928e97ffa00a70e6 Reviewed-on: https://go-review.googlesource.com/40471 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Theophanes authored
When a Tx starts a query, prevent returning the connection to the pool until after the query finishes. Fixes #19058 Change-Id: I2c0480d9cca9eeb173b5b3441a5aeed6f527e0ac Reviewed-on: https://go-review.googlesource.com/40400Reviewed-by:
-
Alberto Donizetti authored
When casting an ideal to complex{64,128}, for example during the evaluation of var a = complex64(0) / 1e-50 we want the compiler to report a division-by-zero error if a divisor would be zero after the cast. We already do this for floats; for example var b = float32(0) / 1e-50 generates a 'division by zero' error at compile time (because float32(1e-50) is zero, and the cast is done before performing the division). There's no such check in the path for complex{64,128} expressions, and no cast is performed before the division in the evaluation of var a = complex64(0) / 1e-50 which compiles just fine. This patch changes the convlit1 function so that complex ideals components (real and imag) are correctly truncated to float{32,64} when doing an ideal -> complex{64, 128} cast. Fixes #11674 Change-Id: Ic5f8ee3c8cfe4c3bb0621481792c96511723d151 Reviewed-on: https://go-review.googlesource.com/37891 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Josh Bleecher Snyder authored
Move it to the x86 package, matching our handling of deferreturn in x86 and arm. While we're here, improve the concurrency safety of both Plan9privates and deferreturn by eagerly initializing them in instinit. Updates #15756 Change-Id: If3b1995c1e4ec816a5443a18f8d715631967a8b1 Reviewed-on: https://go-review.googlesource.com/40408 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lynn Boger authored
A recent performance improvement for PPC64.rules introduced a regression for the case where the size of a move is <= 8 bytes and the value used in the offset field of the instruction is not aligned correctly for the instruction. In the cases where this happened, the assembler was not detecting the incorrect offset and still generated the instruction even though it was invalid. This fix changes the PPC64.rules for the moves that are now failing to include the correct alignment checks, along some additional testcases for gc/ssa for the failing alignments. I will add a fix to the assembler to detect incorrect offsets in another CL. This fixes #19907 Change-Id: I3d327ce0ea6afed884725b1824f9217cef2fe6bf Reviewed-on: https://go-review.googlesource.com/40290Reviewed-by:
Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by:
David Chase <drchase@google.com>
-
Josh Bleecher Snyder authored
It is zeroed pointlessly and never read. Change-Id: I65390501a878f545122ec558cb621b91e394a538 Reviewed-on: https://go-review.googlesource.com/40406 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Lynn Boger authored
Curently the vendor paths are not always searched for imports if the compiler is gccgo. This change generates the vendor paths and adds them with -I as arguments to the gccgo compile. Fixes #15628 Change-Id: I318accbbbd8e6af45475eda399377455a3565880 Reviewed-on: https://go-review.googlesource.com/40432 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
It is only used once and never written to. Switch to a local constant instead. Change-Id: Icdd84e47b81f0de44ad9ed56ab5f4f91df22e6b6 Reviewed-on: https://go-review.googlesource.com/40405 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
