Skip to content

G
go
Switch branch/tag
  1. 11 Sep, 2019 7 commits
    • Lucas Bremgartner's avatar
      encoding/json: fix and optimize marshal for quoted string · 0e015e20
      Lucas Bremgartner authored 
      Since Go 1.2 every string can be marshaled to JSON without error even if it
contains invalid UTF-8 byte sequences. Therefore there is no need to use
Marshal again for the only reason of enclosing the string in double quotes.
Not using Marshal here also removes the error check as there has not been a
way for Marshal to fail anyway.

name          old time/op    new time/op    delta
Issue34127-4     360ns ± 3%     200ns ± 3%  -44.56%  (p=0.008 n=5+5)

name          old alloc/op   new alloc/op   delta
Issue34127-4     56.0B ± 0%     40.0B ± 0%  -28.57%  (p=0.008 n=5+5)

name          old allocs/op  new allocs/op  delta
Issue34127-4      3.00 ± 0%      2.00 ± 0%  -33.33%  (p=0.008 n=5+5)

Fixes #34154

Change-Id: Ib60dc11980f9b20d8bef2982de7168943d632263
GitHub-Last-Rev: 9b0ac1d4c5318b6bf9ed7930320f2bd755f9939c
GitHub-Pull-Request: golang/go#34127
Reviewed-on: https://go-review.googlesource.com/c/go/+/193604Reviewed-by: default avatarDaniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      0e015e20
    • Ruixin(Peter) Bao's avatar
      cmd/compile/internal/s390x: replace 4-byte NOP with a 2-byte NOP on s390x · 11c2411c
      Ruixin(Peter) Bao authored 
      Added a new instruction, NOPH, with the encoding [0x0700](i.e: bcr 0, 0) and
replace the current 4-byte nop that was encoded using the WORD instruction.

This reduces the size of .text section in go binary by around 17KB and make
generated code easier to read.

Change-Id: I6a756df39e93c4415ea6d038ba4af001b8ccb286
Reviewed-on: https://go-review.googlesource.com/c/go/+/194344Reviewed-by: default avatarMichael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      11c2411c
    • Howard Zhang's avatar
      syscall: implement rawVforkSyscall for linux/arm64 · b25ec50b
      Howard Zhang authored 
      This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
"fork/exec ...: cannot allocate memory" failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on linux/arm64.

With CLONE_VM the child process shares the same memory with the parent
process. On its own this would lead to conflicting use of the same
memory, so CLONE_VFORK is used to suspend the parent process until the
child releases the memory when switching to the new program binary
via the exec syscall. When the parent process continues to run, one
has to consider the changes to memory that the child process did,
namely the return address of the syscall function needs to be restored
from a register.

exec.Command() callers can start in a faster manner, as child process who
do exec commands job can be cloned faster via vfork than via fork on arm64.

The same problem was addressed on linux/amd64 via issue #5838.

Updates #31936
Contributed by Howard Zhang <howard.zhang@arm.com> and Bin Lu <bin.lu@arm.com>

Change-Id: Ia99d81d877f564ec60d19f17e596276836576eaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/189418
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      b25ec50b
    • Yuichi Nishiwaki's avatar
      runtime: fix crash during VDSO calls on arm · 904f046e
      Yuichi Nishiwaki authored 
      As discussed in #32912, a crash occurs when go runtime calls a VDSO function (say
__vdso_clock_gettime) and a signal arrives to that thread.
Since VDSO functions temporarily destroy the G register (R10),
Go functions asynchronously executed in that thread (i.e. Go's signal
handler) can try to load data from the destroyed G, which causes
segmentation fault.

To fix the issue a guard is inserted in front of sigtrampgo, so that the control escapes from
signal handlers without touching G in case the signal occurred in the VDSO context.
The test case included in the patch is take from discussion in a relevant thread on github:
https://github.com/golang/go/issues/32912#issuecomment-517874531.
This patch not only fixes the issue on AArch64 but also that on 32bit ARM.

Fixes #32912

Change-Id: I657472e54b7aa3c617fabc5019ce63aa4105624a
GitHub-Last-Rev: 28ce42c4a02a060f08c1b0dd1c9a392123fd2ee9
GitHub-Pull-Request: golang/go#34030
Reviewed-on: https://go-review.googlesource.com/c/go/+/192937
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      904f046e
    • Sven Taute's avatar
      encoding/base32: increase performance and code reuse · 8ef6d6a8
      Sven Taute authored 
      Add benchmarks for the Encode/Decode functions operating on []byte and increase decoding performance by removing the calls to strings.Map/bytes.Map and reusing the newline filtering code that is used by NewDecoder.
Cut allocations in half for DecodeString.

Comparison using the new benchmarks:
name            old time/op    new time/op     delta
Encode            16.7µs ± 1%     17.0µs ± 2%    +2.25%  (p=0.000 n=9+9)
EncodeToString    21.1µs ± 1%     20.9µs ± 1%    -0.96%  (p=0.000 n=10+10)
Decode             141µs ± 1%       54µs ± 1%   -61.51%  (p=0.000 n=10+10)
DecodeString      81.4µs ± 0%     54.7µs ± 1%   -32.79%  (p=0.000 n=9+10)

name            old speed      new speed       delta
Encode           492MB/s ± 1%    481MB/s ± 2%    -2.19%  (p=0.000 n=9+9)
EncodeToString   389MB/s ± 1%    392MB/s ± 1%    +0.97%  (p=0.000 n=10+10)
Decode          93.0MB/s ± 1%  241.6MB/s ± 1%  +159.82%  (p=0.000 n=10+10)
DecodeString     161MB/s ± 0%    240MB/s ± 1%   +48.78%  (p=0.000 n=9+10)

Change-Id: Id53633514a9e14ecd0389d52114b2b8ca64370cb
GitHub-Last-Rev: f4be3cf55caf5b89d76d14b7f32422faff39e3c3
GitHub-Pull-Request: golang/go#30376
Reviewed-on: https://go-review.googlesource.com/c/go/+/163598
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      8ef6d6a8
    • Huan Du's avatar
      reflect: fix panic in DeepEqual when checking a cycle · 4dc11ae2
      Huan Du authored 
      Before this change, when DeepEqual checks values with cycle, it may
panic due to stack overflow.

Here is a sample to reproduce the issue.

    makeCycleMap := func() interface{} {
        cycleMap := map[string]interface{}{}
        cycleMap["foo"] = cycleMap
        return cycleMap
    }

    m1 := makeCycleMap()
    m2 := makeCycleMap()
    reflect.DeepEqual(m1, m2) // stack overflow

The root cause is that DeepEqual fails to cache interface values
in visited map, which is used to detect cycle. DeepEqual calls
CanAddr to check whether a value should be cached or not. However,
all values referenced by interface don't have flagAddr thus all these
values are not cached.

THe fix is to remove CanAddr calls and use underlying ptr in value
directly. As ptr is only read-only in DeepEqual for caching, it's
safe to do so. We don't use UnsafeAddr this time, because this method
panics when CanAddr returns false.

Fixes #33907

Change-Id: I2aa88cc060a2c2192b1d34c129c0aad4bd5597e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/191940
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      4dc11ae2
    • Marko Kungla's avatar
      reflect: enhance docs for IsZero and IsValid · a5026af5
      Marko Kungla authored 
      Make it clear that IsValid checks that we have valid
reflect.Value and not the value of `v`

fixes #34152

Change-Id: Ib3d359eeb3a82bf733b9ed17c777fc4c143bc29c
Reviewed-on: https://go-review.googlesource.com/c/go/+/193841Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      a5026af5
  3. 10 Sep, 2019 13 commits
  5. 09 Sep, 2019 10 commits
  7. 08 Sep, 2019 2 commits
  9. 07 Sep, 2019 7 commits
  11. 06 Sep, 2019 1 commit
    • Matthew Dempsky's avatar
      cmd/compile: rewrite untyped constant conversion logic · 581526ce
      Matthew Dempsky authored 
      This CL detangles the hairy mess that was convlit+defaultlit. In
particular, it makes the following changes:

1. convlit1 now follows the standard typecheck behavior of setting
"n.Type = nil" if there's an error. Notably, this means for a lot of
test cases, we now avoid reporting useless follow-on error messages.
For example, after reporting that "1 << s + 1.0" has an invalid shift,
we no longer also report that it can't be assigned to string.

2. Previously, assignconvfn had some extra logic for trying to
suppress errors from convlit/defaultlit so that it could provide its
own errors with better context information. Instead, this extra
context information is now passed down into convlit1 directly.

3. Relatedly, this CL also removes redundant calls to defaultlit prior
to assignconv. As a consequence, when an expression doesn't make sense
for a particular assignment (e.g., assigning an untyped string to an
integer), the error messages now say "untyped string" instead of just
"string". This is more consistent with go/types behavior.

4. defaultlit2 is now smarter about only trying to convert pairs of
untyped constants when it's likely to succeed. This allows us to
report better error messages for things like 3+"x"; instead of "cannot
convert 3 to string" we now report "mismatched types untyped number
and untyped string".

Passes toolstash-check.

Change-Id: I26822a02dc35855bd0ac774907b1cf5737e91882
Reviewed-on: https://go-review.googlesource.com/c/go/+/187657
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      581526ce
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7