- 05 Oct, 2018 6 commits
-
-
Robert Griesemer authored
Remove assumption that methods associated to concrete (non-interface) types have a fully set up signature. Such methods are found through LookupFieldOrMethod or lookupMethod, or indexed method access from a Named type. Make sure that the method's signature is type-checked before use in those cases. (MethodSets also hold methods but the type checker is not using them but for internal verification. API clients will be using it after all methods have been type-checked.) Some functions such as MissingMethod may now have to type-check a method and for that they need a *Checker. Add helper functions as necessary to provide the additional (receiver) parameter but permit it to be nil if the respective functions are invoked through the API (at which point we know that all methods have a proper signature and thus we don't need the delayed type-check). Since all package-level objects eventually are type-checked through the top-level loop in Checker.packageObjects we are guaranteed that all methods will be type-checked as well. Updates #23203. Updates #26854. Change-Id: I6e48f0016cefd498aa70b776e84a48215a9042c5 Reviewed-on: https://go-review.googlesource.com/c/139425Reviewed-by:
Alan Donovan <adonovan@google.com>
-
https://golang.org/cl/139422Robert Griesemer authored
The prior CL prepared go/types for the situation where methods might not have a type-checked signature when being looked up. The respective adjustments to recvPtr were not correct (but because so far method signatures are type-checked in time, the bug didn't manifest itself). Updates #23203. Updates #26854. Change-Id: I796691d11e6aac84396bdef802ad30715755fcc6 Reviewed-on: https://go-review.googlesource.com/c/139721Reviewed-by:
-
Meng Zhuo authored
The origin tagKey is just dirname if no tags input which will cause pkgCache missmatch if other imported pkg explicit on GOARCH or GOOS This CL will add GOOS and GOARCH to tagKey Fixes #8425 Fixes #21181 Change-Id: Ifc189cf6746d753ad7c7e5bb60621297fc0a4e35 Reviewed-on: https://go-review.googlesource.com/c/138315Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Austin Clements authored
The alloc_m documentation refers to concepts that don't exist (and maybe never did?). alloc_m is also not the API entry point to span allocation. Hence, rewrite the documentation for alloc and alloc_m. While we're here, document why alloc_m must run on the system stack and replace alloc_m's hand-implemented system stack check with a go:systemstack annotation. Change-Id: I30e263d8e53c2774a6614e1b44df5464838cef09 Reviewed-on: https://go-review.googlesource.com/c/139459 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Michael Knyszek <mknyszek@google.com> Reviewed-by:
Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
.rel symbol type is sym.SELFROSECT, and that makes .rel written into .rdata section. But .rel stores code - jump table used for external C functions. So we have to mark whole .rdata section as executable (IMAGE_SCN_MEM_EXECUTE), because of .rel presence in it. Move .rel into .text section, and make .rdata section non executable. I also had to move code that adjusted the size of .rel symbol before calling textaddress, otherwise textaddress would not calculate size of .text section correctly. Fixes #25926 Change-Id: I4962f5de7b367410154c8709adfcd8472de9ac1a Reviewed-on: https://go-review.googlesource.com/c/125455 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Keith Randall authored
On wasm, pcln tables are indexed by "resumption point ID" instead of by pc offset. When finding a deferreturn call, we must find the associated resumption point ID for the deferreturn call. Update #27518 Fixes wasm bug introduced in CL 134637. Change-Id: I3d178a3f5203a06c0180a1aa2309bfb7f3014f0f Reviewed-on: https://go-review.googlesource.com/c/139898Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
- 04 Oct, 2018 19 commits
-
-
Jason Keene authored
This change disables the export-subst and export-ignore attributes when creating zip files for modules. This is done to prevent the ziphash for a given repo/revision from differing based on variables such as git version or size of repo. The full rational for this change is detailed here: https://github.com/golang/go/issues/27153#issuecomment-420763082 Fixes #27153 Change-Id: Ib33f525d91d2581fa0b5d26e70d29620c7e685e9 Reviewed-on: https://go-review.googlesource.com/c/135175 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Bryan C. Mills <bcmills@google.com>
-
Mikio Hara authored
Updates the route package to git rev 68fc911 for: - 68fc911 re-adjust routing message alignment for FreeBSD 386 emulation - 4dfa261 fix typos in comments - ae89d30 avoid unnecessary type conversions Change-Id: I915e614e464acf85a8fc80f36f05a85a9246bb01 Reviewed-on: https://go-review.googlesource.com/c/139817 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ben Shi authored
Currently "ADD $0x123456, Rs, Rd" will load pre-stored 0x123456 from the constant pool and use it for the addition. Total 12 bytes are cost. And so does SUB. This CL breaks it to "ADD 0x123000, Rs, Rd" + "ADD 0x000456, Rd, Rd". Both "0x123000" and "0x000456" can be directly encoded into the instruction binary code. So 4 bytes are saved. 1. The total size of pkg/android_arm64 decreases about 0.3KB. 2. The go1 benchmark show little regression (excluding noise). name old time/op new time/op delta BinaryTree17-4 15.9s ± 0% 15.9s ± 1% +0.10% (p=0.044 n=29+29) Fannkuch11-4 8.72s ± 0% 8.75s ± 0% +0.34% (p=0.000 n=30+24) FmtFprintfEmpty-4 173ns ± 0% 173ns ± 0% ~ (all equal) FmtFprintfString-4 368ns ± 0% 368ns ± 0% ~ (p=0.593 n=30+30) FmtFprintfInt-4 417ns ± 0% 417ns ± 0% ~ (all equal) FmtFprintfIntInt-4 673ns ± 0% 661ns ± 1% -1.70% (p=0.000 n=30+30) FmtFprintfPrefixedInt-4 805ns ± 0% 805ns ± 0% +0.10% (p=0.011 n=30+30) FmtFprintfFloat-4 1.09µs ± 0% 1.09µs ± 0% ~ (p=0.125 n=30+29) FmtManyArgs-4 2.68µs ± 0% 2.68µs ± 0% +0.07% (p=0.004 n=30+30) GobDecode-4 32.9ms ± 0% 33.2ms ± 1% +1.07% (p=0.000 n=29+29) GobEncode-4 29.5ms ± 0% 29.6ms ± 0% +0.26% (p=0.000 n=28+28) Gzip-4 1.38s ± 1% 1.35s ± 3% -1.94% (p=0.000 n=28+30) Gunzip-4 139ms ± 0% 139ms ± 0% +0.10% (p=0.000 n=28+29) HTTPClientServer-4 745µs ± 5% 742µs ± 3% ~ (p=0.405 n=28+29) JSONEncode-4 49.5ms ± 1% 49.9ms ± 0% +0.89% (p=0.000 n=30+30) JSONDecode-4 264ms ± 1% 264ms ± 0% +0.25% (p=0.001 n=30+30) Mandelbrot200-4 16.6ms ± 0% 16.6ms ± 0% ~ (p=0.507 n=29+29) GoParse-4 15.9ms ± 0% 16.0ms ± 1% +0.91% (p=0.002 n=23+30) RegexpMatchEasy0_32-4 379ns ± 0% 379ns ± 0% ~ (all equal) RegexpMatchEasy0_1K-4 1.31µs ± 0% 1.31µs ± 0% +0.09% (p=0.008 n=27+30) RegexpMatchEasy1_32-4 357ns ± 0% 358ns ± 0% +0.28% (p=0.000 n=28+29) RegexpMatchEasy1_1K-4 2.04µs ± 0% 2.04µs ± 0% ~ (p=0.850 n=30+30) RegexpMatchMedium_32-4 587ns ± 0% 589ns ± 0% +0.33% (p=0.000 n=30+30) RegexpMatchMedium_1K-4 162µs ± 0% 163µs ± 0% ~ (p=0.351 n=30+29) RegexpMatchHard_32-4 9.54µs ± 0% 9.60µs ± 0% +0.59% (p=0.000 n=28+30) RegexpMatchHard_1K-4 287µs ± 0% 287µs ± 0% +0.11% (p=0.000 n=26+29) Revcomp-4 2.50s ± 0% 2.50s ± 0% -0.13% (p=0.012 n=28+27) Template-4 312ms ± 1% 312ms ± 1% +0.20% (p=0.015 n=27+30) TimeParse-4 1.68µs ± 0% 1.68µs ± 0% -0.35% (p=0.000 n=30+30) TimeFormat-4 1.66µs ± 0% 1.64µs ± 0% -1.20% (p=0.000 n=25+29) [Geo mean] 246µs 246µs -0.00% name old speed new speed delta GobDecode-4 23.3MB/s ± 0% 23.1MB/s ± 1% -1.05% (p=0.000 n=29+29) GobEncode-4 26.0MB/s ± 0% 25.9MB/s ± 0% -0.25% (p=0.000 n=29+28) Gzip-4 14.1MB/s ± 1% 14.4MB/s ± 3% +1.94% (p=0.000 n=27+30) Gunzip-4 139MB/s ± 0% 139MB/s ± 0% -0.10% (p=0.000 n=28+29) JSONEncode-4 39.2MB/s ± 1% 38.9MB/s ± 0% -0.88% (p=0.000 n=30+30) JSONDecode-4 7.37MB/s ± 0% 7.35MB/s ± 0% -0.26% (p=0.001 n=30+30) GoParse-4 3.65MB/s ± 0% 3.62MB/s ± 1% -0.86% (p=0.001 n=23+30) RegexpMatchEasy0_32-4 84.3MB/s ± 0% 84.3MB/s ± 0% ~ (p=0.126 n=27+26) RegexpMatchEasy0_1K-4 784MB/s ± 0% 783MB/s ± 0% -0.10% (p=0.003 n=27+30) RegexpMatchEasy1_32-4 89.5MB/s ± 0% 89.3MB/s ± 0% -0.20% (p=0.000 n=27+29) RegexpMatchEasy1_1K-4 502MB/s ± 0% 502MB/s ± 0% ~ (p=0.858 n=30+28) RegexpMatchMedium_32-4 1.70MB/s ± 0% 1.70MB/s ± 0% -0.25% (p=0.000 n=30+30) RegexpMatchMedium_1K-4 6.30MB/s ± 0% 6.30MB/s ± 0% ~ (all equal) RegexpMatchHard_32-4 3.35MB/s ± 0% 3.33MB/s ± 0% -0.47% (p=0.000 n=30+30) RegexpMatchHard_1K-4 3.57MB/s ± 0% 3.56MB/s ± 0% -0.20% (p=0.000 n=27+30) Revcomp-4 102MB/s ± 0% 102MB/s ± 0% +0.14% (p=0.008 n=28+28) Template-4 6.23MB/s ± 0% 6.21MB/s ± 1% -0.21% (p=0.009 n=21+30) [Geo mean] 24.1MB/s 24.0MB/s -0.16% Change-Id: Ifcef3edb667540e2d86e586c23afcfbc2cf1340b Reviewed-on: https://go-review.googlesource.com/c/134536 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alberto Donizetti authored
The TestLldbPython test is known to fail with very old lldb releases (3.8 and older). Skip the test when the lldb found on the system is too old. Fixes #22299 Change-Id: I8f78d6c0d995118f806dae87f3f04a9726473116 Reviewed-on: https://go-review.googlesource.com/c/139397Reviewed-by:
-
Brad Fitzpatrick authored
It requires a DLL that's not available on windows/arm apparently. Fixes #27904 Change-Id: I082a273f62976b7184636c6aeca6201a7871d238 Reviewed-on: https://go-review.googlesource.com/c/139720 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Plekhanov Maxim authored
name old time/op new time/op delta PowInt 55.7ns ± 1% 53.4ns ± 2% -4.15% (p=0.000 n=9+9) PowFrac 133ns ± 1% 133ns ± 2% ~ (p=0.587 n=8+9) Change-Id: Ica0f4c2cbd554f2195c6d1762ed26742ff8e3924 Reviewed-on: https://go-review.googlesource.com/c/85375Reviewed-by:
-
Plekhanov Maxim authored
goos: linux goarch: amd64 pkg: math name old time/op new time/op delta Mod 64.7ns ± 2% 63.7ns ± 2% -1.52% (p=0.003 n=8+10) Change-Id: I851bec0fd6c223dab73e4a680b7393d49e81a0e8 Reviewed-on: https://go-review.googlesource.com/c/85095Reviewed-by:
-
Brad Fitzpatrick authored
Change-Id: I69582662aeee7344226856c24907516ddfc92f60 Reviewed-on: https://go-review.googlesource.com/c/139717 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Elias Naur <elias.naur@gmail.com>
-
Austin Clements authored
Currently the table of arena sizes mixes the number of entries in the L1 with the size of the L2. While the size of the L2 is important, this makes it hard to see what's actually going on because there's an implicit factor of sys.PtrSize. This changes the L2 column to say both the number of entries and the size that results in. This should hopefully make the relations between the columns of the table clearer, since they can now be plugged directly into the given formula. Change-Id: Ie677adaef763b893a2f620bd4fc3b8db314b3a1e Reviewed-on: https://go-review.googlesource.com/c/139697Reviewed-by:
-
Austin Clements authored
mheap_.treapalloc.alloc() already returns a zeroed treapNode. Don't bother re-zeroing all of the fields. Change-Id: Iea317040fbb72dfe5ef1e2c56c287680b065f2d9 Reviewed-on: https://go-review.googlesource.com/c/139460 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Tobias Klauser authored
This fixes the build for long-running tests after CL 139338 Change-Id: Ib8adfa785d41c736188e2ff7e14125de045b96b9 Reviewed-on: https://go-review.googlesource.com/c/139637 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
LookupFieldOrMethod needs to know if a method receiver is a pointer type. Until now this was computed from the the method signature's receiver, which required the method signature to be type-checked. Furthermore, it required the receiver to be set before the method signature was fully type-checked in some cases (see issue #6638). This CL remembers this property during object resolution, when we know it from the source. With this CL, method signatures don't need to be type-checked before they can be looked up; this is a first step towards separating type checking of types and type-checking of associated methods. Updates #23203. Updates #26854. Change-Id: Ie3eb7976e8fe8176ea1b284fa7471a4b7000f80b Reviewed-on: https://go-review.googlesource.com/c/139422 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I0490098a7235458c5aede1135426a9f19f8584a7 Reviewed-on: https://go-review.googlesource.com/c/76312 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
In preparation for followup CL merging TPTR32 and TPTR64, move TPTR32 from the small-types fast path to the generic 64-bit fallback code so that it's in the same case clause as TPTR64. This should be safe, but theoretically it could change semantics because TPTR32 used to always be assumed to be "small", whereas now it will only be considered small for values less than 1<<31. This change is done in a separate CL so that it's more easily identified by git bisection in case it does introduce regressions. Change-Id: I6c7bb253d4e4d95c530a6e05a1147905674b55ca Reviewed-on: https://go-review.googlesource.com/c/139517 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Change-Id: Ie4bab0b74d5a4e1aecd8501a48176b2e9a3d8c42 Reviewed-on: https://go-review.googlesource.com/c/76311 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Kir Kolyshkin authored
As pointed out in https://github.com/golang/go/issues/26463, HOME (or equivalent) environment variable (rather than the value obtained by parsing /etc/passwd or the like) should be used to obtain user's home directory. Since commit fa1a49aa there's a method to obtain user's home directory -- use it here. Change-Id: I852fbb24249bcfe08f3874fae6e7b9d01d869190 Reviewed-on: https://go-review.googlesource.com/c/139426Reviewed-by:
-
Michael Fraenkel authored
Fixes #13491 Change-Id: Ic0525d8ee90f47d0d23c1485919aee13d2400494 Reviewed-on: https://go-review.googlesource.com/c/139537 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
uropek authored
Change-Id: Id21cdce35963dcdb96cc06252170590224c5aa17 GitHub-Last-Rev: 429dad0ceba123415af308179d0d2aa9773e6323 GitHub-Pull-Request: golang/go#28000 Reviewed-on: https://go-review.googlesource.com/c/139424Reviewed-by:
-
Richard Musiol authored
This commit makes syscall on js/wasm use the asynchronous variants of functions in Node.js' fs module. This enables concurrency and allows the API of the fs module to be implemented with an alternative backend that only supports asynchronous operations. Updates #26051. Change-Id: Ibe1dcc988469fc11c3b8d8d49de439c12ddaafce Reviewed-on: https://go-review.googlesource.com/c/137236 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 03 Oct, 2018 15 commits
-
-
Brad Fitzpatrick authored
Fixes #22614 Change-Id: I220afbaaeab4dec6d59eeeef12107234a77f1587 Reviewed-on: https://go-review.googlesource.com/c/139419Reviewed-by:
-
Don Byington authored
Fixes #27990 Change-Id: I0f09fc6f68cec770b1c26eed2315afbf6bf6cd4d GitHub-Last-Rev: 8486e6d5019c6c21b10e5fcf10a2727cf2705174 GitHub-Pull-Request: golang/go#27991 Reviewed-on: https://go-review.googlesource.com/c/139417 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lynn Boger authored
The following adds support for load and store instructions with index registers, and adds rules to take advantage of those instructions. Examples of improvements: crypto/rc4: name old time/op new time/op delta RC4_128 445ns ± 0% 404ns ± 0% -9.21% (p=0.029 n=4+4) RC4_1K 3.46µs ± 0% 3.13µs ± 0% -9.29% (p=0.029 n=4+4) RC4_8K 27.0µs ± 0% 24.7µs ± 0% -8.83% (p=0.029 n=4+4) crypto/des: name old time/op new time/op delta Encrypt 276ns ± 0% 264ns ± 0% -4.35% (p=0.029 n=4+4) Decrypt 278ns ± 0% 263ns ± 0% -5.40% (p=0.029 n=4+4) TDESEncrypt 683ns ± 0% 645ns ± 0% -5.56% (p=0.029 n=4+4) TDESDecrypt 684ns ± 0% 641ns ± 0% -6.29% (p=0.029 n=4+4) crypto/sha1: name old time/op new time/op delta Hash8Bytes 661ns ± 0% 635ns ± 0% -3.93% (p=1.000 n=1+1) Hash320Bytes 2.70µs ± 0% 2.56µs ± 0% -5.26% (p=1.000 n=1+1) Hash1K 7.14µs ± 0% 6.78µs ± 0% -5.03% (p=1.000 n=1+1) Hash8K 52.1µs ± 0% 49.4µs ± 0% -5.14% (p=1.000 n=1+1) Change-Id: I03810e90fcc20029975a323f06bfa086c973c2b0 Reviewed-on: https://go-review.googlesource.com/c/135975 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Munday <mike.munday@ibm.com>
-
Brad Fitzpatrick authored
Fixes #26463 Change-Id: Iaef1c7456ffaeadeead6027a37d09c44a3d05bd5 Reviewed-on: https://go-review.googlesource.com/c/139418Reviewed-by:
-
Clément Chigot authored
This commit adds AIX operating system to internal/syscall package for ppc64 architecture. Updates: #25893 Change-Id: I5c3a9d4403ca170a7e894e06e68b83387d09b816 Reviewed-on: https://go-review.googlesource.com/c/138718 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
When an invalid UTF-8 byte sequence is decoded in a range loop over a string a utf8.RuneError rune is returned. This is not distinguishable from decoding the valid '\uFFFD' sequence representing utf8.RuneError from a string without further checks within the range loop. The previous Map code did not do any extra checks and would thereby not map invalid UTF-8 byte sequences correctly when those were mapping to utf8.RuneError. Fix this by adding the extra checks necessary to distinguish the decoding of invalid utf8 byte sequences from decoding the sequence for utf8.RuneError when the mapping of a rune is utf8.RuneError. This fix does not result in a measureable performance regression: name old time/op new time/op delta ByteByteMap 1.05µs ± 3% 1.03µs ± 3% ~ (p=0.118 n=10+10) Map/identity/ASCII 169ns ± 2% 170ns ± 1% ~ (p=0.501 n=9+10) Map/identity/Greek 298ns ± 1% 303ns ± 4% ~ (p=0.338 n=10+10) Map/change/ASCII 323ns ± 3% 325ns ± 4% ~ (p=0.679 n=8+10) Map/change/Greek 628ns ± 5% 635ns ± 1% ~ (p=0.460 n=10+9) MapNoChanges 120ns ± 4% 119ns ± 1% ~ (p=0.496 n=10+9) Fixes #26305 Change-Id: I70e99fa244983c5040756fa4549ac1e8cb6022c3 Reviewed-on: https://go-review.googlesource.com/c/131495Reviewed-by:
-
Clément Chigot authored
This commit adds AIX operating system to internal/poll package for ppc64 architecture. Updates: #25893 Change-Id: I9b1da9255012de58f16547c1b18f8840485da170 Reviewed-on: https://go-review.googlesource.com/c/138717 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Clément Chigot authored
This commit adds AIX operating system to runtime package for ppc64 architecture. Only new files and minor changes are in this commit. Others modifications in files like asm_ppc64.s will be in separate commits. Updates: #25893 Change-Id: I9c5e073f5f3debb43b004ad1167694a5afd31cfd Reviewed-on: https://go-review.googlesource.com/c/138716 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently, the Windows profile loop isn't robust against racing with unminit. For example, T1 is running profileloop1, T2 is another thread T1: thread := atomic.Loaduintptr(&T2.thread) T2: calls unminit, which does CloseHandle(T2.thread) T1: attempts to suspends T2 In this case the SuspendThread will fail, but currently we ignore this failure and forge ahead, which will cause further failures and probably bad profile data. Handle this race by defending against SuspendThread failing. If SuspendThread succeeds, then we know the thread is no longer going anywhere. Change-Id: I4726553239b17f05ca07a0cf7df49631e0cb550d Reviewed-on: https://go-review.googlesource.com/c/129685 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
Austin Clements authored
The debug call injection tests will freeze when run under a debugger because they depend on catching SIGTRAP, which is usually swallowed by a debugger. Change-Id: If6b86ca279b0489182990dd513444ca3062973f1 Reviewed-on: https://go-review.googlesource.com/c/139437 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
And start using it elsewhere in the standard library, removing the copies in the process. While at it, rewrite the io.WriteString godoc to be more clear, since it can now make reference to the defined interface. Fixes #27946. Change-Id: Id5ba223c09c19e5fb49815bd3b1bd3254fc786f3 Reviewed-on: https://go-review.googlesource.com/c/139457 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Keith Randall authored
Allocate a long linked list on the stack. This tests both lots of live stack objects, and lots of intra-stack pointers to those objects. Change-Id: I169e067416455737774851633b1e5367e10e1cf2 Reviewed-on: https://go-review.googlesource.com/c/135296 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com> Reviewed-by:
-
Keith Randall authored
When a function triggers a signal (like a segfault which translates to a nil pointer exception) during execution, a sigpanic handler is just below it on the stack. The function itself did not stop at a safepoint, so we have to figure out what safepoint we should use to scan its stack frame. Previously we used the site of the most recent defer to get the live variables at the signal site. That answer is not quite correct, as explained in #27518. Instead, use the site of a deferreturn call. It has all the right variables marked as live (no args, all the return values, except those that escape to the heap, in which case the corresponding PAUTOHEAP variables will be live instead). This CL requires stack objects, so that all the local variables and args referenced by the deferred closures keep the right variables alive. Fixes #27518 Change-Id: Id45d8a8666759986c203181090b962e2981e48ca Reviewed-on: https://go-review.googlesource.com/c/134637Reviewed-by:
-
Keith Randall authored
The previous CL introduced stack objects. This CL removes the old ambiguously live liveness analysis. After this CL we're relying on stack objects exclusively. Update a bunch of liveness tests to reflect the new world. Fixes #22350 Change-Id: I739b26e015882231011ce6bc1a7f426049e59f31 Reviewed-on: https://go-review.googlesource.com/c/134156Reviewed-by:
-
Keith Randall authored
Rework how the compiler+runtime handles stack-allocated variables whose address is taken. Direct references to such variables work as before. References through pointers, however, use a new mechanism. The new mechanism is more precise than the old "ambiguously live" mechanism. It computes liveness at runtime based on the actual references among objects on the stack. Each function records all of its address-taken objects in a FUNCDATA. These are called "stack objects". The runtime then uses that information while scanning a stack to find all of the stack objects on a stack. It then does a mark phase on the stack objects, using all the pointers found on the stack (and ancillary structures, like defer records) as the root set. Only stack objects which are found to be live during this mark phase will be scanned and thus retain any heap objects they point to. A subsequent CL will remove all the "ambiguously live" logic from the compiler, so that the stack object tracing will be required. For this CL, the stack tracing is all redundant with the current ambiguously live logic. Update #22350 Change-Id: Ide19f1f71a5b6ec8c4d54f8f66f0e9a98344772f Reviewed-on: https://go-review.googlesource.com/c/134155Reviewed-by:
-
