Previously, we wrote "kill" to the process control file
to kill a program. This is problematic because it doesn't
let the program gracefully exit.
This matters especially if the process we're killing is a
Go program. On Unix, sending SIGKILL to a Go program will
automatically kill all runtime threads. On Plan 9, there
are no threads so when the program wants to exit it has to
somehow signal all of the runtime processes. It can't do
this if we mercilessly kill it by writing to it's control
file.
Instead, we now send it a note to invoke it's note handler
and let it perform any cleanup before exiting.
LGTM=rsc
R=rsc, 0intro
CC=golang-codereviews
https://golang.org/cl/74440044
On Plan 9, the kernel disallows the use of floating point
instructions while handling a note. Previously, we worked
around this by using a simple loop in place of memmove.
When I added that work-around, I verified that all paths
from the note handler didn't end up calling memmove. Now
that memclr is using SSE instructions, the same process
will have to be done again.
Instead of doing that, however, this CL just punts and
uses unoptimized functions everywhere on Plan 9.
LGTM=rsc
R=rsc, 0intro
CC=golang-codereviews
https://golang.org/cl/73830044
syscall.naclWrite was missing from sys_nacl_386.s
This gets ./make.bash passing, but doesn't pass validation. I'm not sure if this is the fault of this change, or validation was broken anyway.
LGTM=rsc
R=minux.ma, rsc
CC=golang-codereviews
https://golang.org/cl/74510043
1. Fix the bug that shrinkstack returns memory to heap.
This causes growslice to misbehave (it manually initialized
blocks, and in efence mode shrinkstack's free leads to
partially-initialized blocks coming out of growslice.
Which in turn causes GC to crash while treating the garbage
as Eface/Iface.
2. Enable efence for stack segments.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr
https://golang.org/cl/74080043
The garbage collector uses type information to guide the
traversal of the heap. If it sees a field that should be a string,
it marks the object pointed at by the string data pointer as
visited but does not bother to look at the data, because
strings contain bytes, not pointers.
If you save s[len(s):] somewhere, though, the string data pointer
actually points just beyond the string data; if the string data
were exactly the size of an allocated block, the string data
pointer would actually point at the next block. It is incorrect
to mark that next block as visited and not bother to look at
the data, because the next block may be some other type
entirely.
The fix is to ignore strings with zero length during collection:
they are empty and can never become non-empty: the base
pointer will never be used again. The handling of slices already
does this (but using cap instead of len).
This was not a bug in Go 1.2, because until January all string
allocations included a trailing NUL byte not included in the
length, so s[len(s):] still pointed inside the string allocation
(at the NUL).
This bug was causing the crashes in test/run.go. Specifically,
the parsing of a regexp in package regexp/syntax allocated a
[]syntax.Inst with rounded size 1152 bytes. In fact it
allocated many such slices, because during the processing of
test/index2.go it creates thousands of regexps that are all
approximately the same complexity. That takes a long time, and
test/run works on other tests in other goroutines. One such
other test is chan/perm.go, which uses an 1152-byte source
file. test/run reads that file into a []byte and then calls
strings.Split(string(src), "\n"). The string(src) creates an
1152-byte string - and there's a very good chance of it
landing next to one of the many many regexp slices already
allocated - and then because the file ends in a \n,
strings.Split records the tail empty string as the final
element in the slice. A garbage collection happens at this
point, the collection finds that string before encountering
the []syntax.Inst data it now inadvertently points to, and the
[]syntax.Inst data is not scanned for the pointers that it
contains. Each syntax.Inst contains a []rune, those are
missed, and the backing rune arrays are freed for reuse. When
the regexp is later executed, the runes being searched for are
no longer runes at all, and there is no match, even on text
that should match.
On 64-bit machines the pointer in the []rune inside the
syntax.Inst is larger (along with a few other pointers),
pushing the []syntax.Inst backing array into a larger size
class, avoiding the collision with chan/perm.go's
inadvertently sized file.
I expect this was more prevalent on OS X than on Linux or
Windows because those managed to run faster or slower and
didn't overlap index2.go with chan/perm.go as often. On the
ARM systems, we only run one errorcheck test at a time, so
index2 and chan/perm would never overlap.
It is possible that this bug is the root cause of other crashes
as well. For now we only know it is the cause of the test/run crash.
Many thanks to Dmitriy for help debugging.
Fixes#7344.
Fixes#7455.
LGTM=r, dvyukov, dave, iant
R=golang-codereviews, dave, r, dvyukov, delpontej, iant
CC=golang-codereviews, khr
https://golang.org/cl/74250043
For now Note, futexsleep and futexwakeup are designed for threads,
not for processes. The explicit use of UMTX_OP_WAIT_UINT_PRIVATE and
UMTX_OP_WAKE_PRIVATE can avoid unnecessary traversals of VM objects,
to hit undiscovered bugs related to VM system on SMP/SMT/NUMA
environment.
Update #7496
LGTM=iant
R=golang-codereviews, gobot, iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/72760043
Solaris doesn't have struct ip_mreqn, instead it uses struct ip_mreq
and struct group_req with struct sockaddr_storage.
Also fixes incorrect SockaddrDatalink.
Update #7399
LGTM=aram, iant
R=golang-codereviews, aram, gobot, iant
CC=golang-codereviews
https://golang.org/cl/73920043
This CL is a reformulation of CL 73110043 containing only the minimum required to get the nacl builds compiling.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/74220043
The comment for 'Clean' function is prepended with spaces instead of
a single tab, resulting in visually misaligned comment in the generated
documentation.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/73840043
The change to signal_amd64.c from CL 15790043 was not merged correctly.
This CL reapplies the change, renaming the file to signal_amd64x.c and adds the appropriate build tags.
LGTM=iant, bradfitz
R=rsc, iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/72790043
Spans are now private to threads, and the loop
is removed from all other functions.
Remove it from marknogc for consistency.
LGTM=khr, rsc
R=golang-codereviews, bradfitz, khr
CC=golang-codereviews, khr, rsc
https://golang.org/cl/72520043
Not many windows users have perl installed. They can just use
standard go tools instead. Also mkerrors_windows.sh script
removed - we don't add any new "unix" errors to windows
syscall package anymore.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/41060044
Thanks to Ian for spotting these.
runtime.h: define uintreg correctly.
stack.c: address warning caused by the type of uintreg being 32 bits on amd64p32.
Commentary (mainly for my own use)
nacl/amd64p32 defines a machine with 64bit registers, but address space is limited to a 4gb window (the window is placed randomly inside the full 48 bit virtual address space of a process). To cope with this 6c defines _64BIT and _64BITREG.
_64BITREG is always defined by 6c, so both GOARCH=amd64 and GOARCH=amd64p32 use 64bit wide registers.
However _64BIT itself is only defined when 6c is compiling for amd64 targets. The definition is elided for amd64p32 environments causing int, uint and other arch specific types to revert to their 32bit definitions.
LGTM=iant
R=iant, rsc, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/72860046
gc does not report this as an error, but go/types does.
(I suspect that constructing a closure counts as a reference
to &all in gc's implementation).
This is not a tool bug, since the spec doesn't require
implementations to implement this check, but it does
illustrate that dialect variations are always a nuisance.
LGTM=rsc, bradfitz
R=bradfitz
CC=golang-codereviews, gri, rsc
https://golang.org/cl/73850043
Previously, passing a long duration to ParseDuration could result in
random, even negative, values.
LGTM=r
R=golang-codereviews, bradfitz, r
CC=golang-codereviews
https://golang.org/cl/72120043
CL 69340044 requires that syscall.SO_ERROR be defined on all unix like platforms. Add SO_ERROR to the list of dummy constants in sycall/net_nacl.go.
LGTM=bradfitz
R=iant, rsc, mikioh.mikioh, bradfitz
CC=golang-codereviews
https://golang.org/cl/73100043
If we report a leak, make sure we've waited long enough to be sure.
The new sleep regimen waits 1.05 seconds before failing; the old
one waited 0.005 seconds.
(The single linux/amd64 failure in this test feels more like a
timing problem than a leak. I don't want to spend time on it unless
we're sure.)
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/72630043
We provide amd64p32 implementations for md5 and sha1 so we need to exclude amd64p32 from the generic implementations in those packages.
Fixes build once CL 72360044 lands.
LGTM=agl, remyoudompheng
R=rsc, bradfitz, agl, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/72460043
This code being buggy is the only explanation I can come up
with for issue 7325. It's probably not, but the only alternative
is a Windows kernel bug. Comment this out to see what breaks
or gets fixed.
Update #7325
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/72590044
From the trace it appears that stackalloc is being
called with 0x1800 which is 6k = 4k + (StackSystem=2k).
Make StackSystem 4k too, to make stackalloc happy.
It's already 4k on windows/amd64.
TBR=khr
CC=golang-codereviews
https://golang.org/cl/72600043
There are at least 3 bugs:
1. g->stacksize accounting is broken during copystack/shrinkstack
2. stktop->free is not properly maintained during copystack/shrinkstack
3. stktop->free logic is broken:
we can have stktop->free==FixedStack,
and we will free it into stack cache,
but it actually comes from heap as the result of non-copying segment shrink
This shows as at least spurious races on race builders (maybe something else as well I don't know).
The idea behind the refactoring is to consolidate stacksize and
segment origin logic in stackalloc/stackfree.
Fixes#7490.
LGTM=rsc, khr
R=golang-codereviews, rsc, khr
CC=golang-codereviews
https://golang.org/cl/72440043
Recursive panics leave dangling Panic structs in g->panic stack.
At best it leads to a Defer leak and incorrect output on a subsequent panic.
At worst it arbitrary corrupts heap.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/72480043
One reason the sync.Pool finalizer test can fail is that
this function's ef1 contains uninitialized data that just
happens to point at some of the old pool. I've seen this cause
retention of a single pool cache line (32 elements) on arm.
Really we need liveness information for C functions, but
for now we can be more careful about data in long-lived
C functions that block.
LGTM=bradfitz, dvyukov
R=golang-codereviews, bradfitz, dvyukov
CC=golang-codereviews, iant, khr
https://golang.org/cl/72490043
Instead, split the underlying storage in half and
free just half of it.
Shrinking without copying lets us reclaim storage used
by a previously profligate Go routine that has now blocked
inside some C code.
To shrink in place, we need all stacks to be a power of 2 in size.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/69580044
Two memory allocator bug fixes.
- efence is not maintaining the proper heap metadata
to make eventual memory reuse safe, so use SysFault.
- now that our heap PageSize is 8k but most hardware
uses 4k pages, SysAlloc and SysReserve results must be
explicitly aligned. Do that in a few more call sites and
document this fact in malloc.h.
Fixes#7448.
LGTM=iant
R=golang-codereviews, josharian, iant
CC=dvyukov, golang-codereviews
https://golang.org/cl/71750048
I've just needed the G status on fault to debug runtime bug.
For some reason we print everything except header here.
Make it more informative and consistent.
R=rsc
CC=golang-codereviews
https://golang.org/cl/67870056
Implement custom assembly thunks for hot race calls (memory accesses and function entry/exit).
The thunks extract caller pc, verify that the address is in heap or global and switch to g0 stack.
Before:
ok regexp 3.692s
ok compress/bzip2 9.461s
ok encoding/json 6.380s
After:
ok regexp 2.229s (-40%)
ok compress/bzip2 4.703s (-50%)
ok encoding/json 3.629s (-43%)
For comparison, normal non-race build:
ok regexp 0.348s
ok compress/bzip2 0.304s
ok encoding/json 0.661s
Race build:
ok regexp 2.229s (+540%)
ok compress/bzip2 4.703s (+1447%)
ok encoding/json 3.629s (+449%)
Also removes some race-related special cases from cgocall and scheduler.
In long-term it will allow to remove cyclic runtime/race dependency on cmd/cgo.
Fixes#4249.
Fixes#7460.
Update #6508
Update #6688
R=iant, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/55100044
During the glob decoding process interface values are set to concrete
values after a test for assignability. If the assignability test fails
a slightly vague error message is produced. While technically accurate
the error message does not clearly describe the problem.
Rewrite the error message to include the usage of the word assignable,
which makes it clear the concrete value type is not assignable to the
interface value type.
Fixes#6467.
LGTM=r
R=golang-codereviews, rsc, r
CC=golang-codereviews
https://golang.org/cl/71590043
32-bit Windows uses "structured exception handling" (SEH) to
handle hardware faults: that there is a per-thread linked list
of fault handlers maintained in user space instead of
something like Unix's signal handlers. The structures in the
linked list are required to live on the OS stack, and the
usual discipline is that the function that pushes a record
(allocated from the current stack frame) onto the list pops
that record before returning. Not to pop the entry before
returning creates a dangling pointer error: the list head
points to a stack frame that no longer exists.
Go pushes an SEH record in the top frame of every OS thread,
and that record suffices for all Go execution on that thread,
at least until cgo gets involved.
If we call into C using cgo, that called C code may push its
own SEH records, but by the convention it must pop them before
returning back to the Go code. We assume it does, and that's
fine.
If the C code calls back into Go, we want the Go SEH handler
to become active again, not whatever C has set up. So
runtime.callbackasm1, which handles a call from C back into
Go, pushes a new SEH record before calling the Go code and
pops it when the Go code returns. That's also fine.
It can happen that when Go calls C calls Go like this, the
inner Go code panics. We allow a defer in the outer Go to
recover the panic, effectively wiping not only the inner Go
frames but also the C calls. This sequence was not popping the
SEH stack up to what it was before the cgo calls, so it was
creating the dangling pointer warned about above. When
eventually the m stack was used enough to overwrite the
dangling SEH records, the SEH chain was lost, and any future
panic would not end up in Go's handler.
The bug in TestCallbackPanic and friends was thus creating a
situation where TestSetPanicOnFault - which causes a hardware
fault - would not find the Go fault handler and instead crash
the binary.
Add checks to TestCallbackPanicLocked to diagnose the mistake
in that test instead of leaving a bad state for another test
case to stumble over.
Fix bug by restoring SEH chain during deferred "endcgo"
cleanup.
This bug is likely present in Go 1.2.1, but since it depends
on Go calling C calling Go, with the inner Go panicking and
the outer Go recovering the panic, it seems not important
enough to bother fixing before Go 1.3. Certainly no one has
complained.
Fixes#7470.
LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=golang-codereviews, iant, khr
https://golang.org/cl/71440043
Regenerate z-files for DragonFly BSD 3.6.
F_DUP_FD_CLOEXEC is now supported, so remove the zero value constant
from types_dragonfly.go so that we use the generated value from the
z-files.
LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/70080047
The format of the DragonFly BSD syscalls.master file has changed
slightly - update mksysnum_dragonfly.pl to match.
LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/71460044
Disable the "udp" to IPv6 unicast address on the loopback interface
test under DragonFly BSD. This currently returns a local address of
0.0.0.1, rather than an IPv6 address with zone identifier.
Update #7473
LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/71500044
Performing multiple connect system calls on a non-blocking socket
under DragonFly BSD does not necessarily result in errors from earlier
connect calls being returned, particularly if we are connecting to
localhost. Instead, once netpoll tells us that the socket is ready,
get the SO_ERROR socket option to see if the connection succeeded
or failed.
Fixes#7474
LGTM=mikioh.mikioh
R=mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/69340044
Added test cases and expanded test harness to handle token end
positions.
Also: Make sure token end positions are never outside the valid
position range, as was possible in case of parse errors.
Fixes#7458.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/70190046
the crypto/tls revision d3d43f270632 (CL 67010043, requiring ServerName or InsecureSkipVerify) breaks net/smtp,
since it seems impossible to do SMTP via TLS anymore. i've tried to fix this by simply using a tls.Config with
ServerName, instead of a nil *tls.Config. without this fix, doing SMTP with TLS results in error "tls: either
ServerName or InsecureSkipVerify must be specified in the tls.Config".
testing: the new method TestTlsClient(...) sets up a skeletal smtp server with tls capability, and test client
injects a "fake" certificate allowing tls to work on localhost; thus, the modification to SendMail(...) enabling
this.
Fixes#7437.
LGTM=bradfitz
R=golang-codereviews, josharian, bradfitz
CC=golang-codereviews
https://golang.org/cl/70380043
The network connection dies differently from the server's
perspective on (some) Windows when the client goes away. Match
on the common prefix (common to Unix and Windows) instead of
the network error part.
Fixes#7456
LGTM=josharian
R=golang-codereviews, josharian
CC=alex.brainman, golang-codereviews, iant
https://golang.org/cl/70010050
For non-closure functions, the context register is uninitialized
on entry and will not be used, but morestack saves it and then the
garbage collector treats it as live. This can be a source of memory
leaks if the context register points at otherwise dead memory.
Avoid this by introducing a parallel set of morestack functions
that clear the context register, and use those for the non-closure functions.
I hope this will help with some of the finalizer flakiness, but it probably won't.
Fixes#7244.
LGTM=dvyukov
R=khr, dvyukov
CC=golang-codereviews
https://golang.org/cl/71030044
I have one machine where this 25 test run is flaky
and fails ("21 >= 21"), but 50 works everywhere.
LGTM=josharian
R=josharian
CC=golang-codereviews
https://golang.org/cl/67870053
It mentioned true and false for error values. Instead, just
don't mention the error semantics, as they match normal Go
conventions (if error is non-nil, the other value is
meaningless). We generally only document error values when
they're interesting (where non-nil, non-nil is valid, or the
error value can be certain known values or types).
Fixes#7464
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/68440044
The flakiness appears to be just in tests, not in the actual code.
Specifically, the many tests call runtime.GC once and expect that
the finalizers will be running in the background when GC returns.
Now that the sweep phase is concurrent with execution, however,
the finalizers will not be run until sweep finishes, which might
be quite a bit later. To force sweep to finish, implement runtime.GC
by calling the actual collection twice. The second will complete the
sweep from the first.
This was reliably broken after a few runs before the CL and now
passes tens of runs:
while GOMAXPROCS=2 ./runtime.test -test.run=Finalizer -test.short \
-test.timeout=300s -test.cpu=$(perl -e 'print ("1,2,4," x 100) . "1"')
do true; done
Fixes#7328.
LGTM=dvyukov
R=dvyukov, dave
CC=golang-codereviews
https://golang.org/cl/71080043
The exception handler runs on the ordinary g stack,
and the stack copier is now trying to do a traceback
across it. That's never been needed before, so it was
unimplemented. Implement it, in all its ugliness.
Fixes windows/amd64 build.
TBR=khr
CC=golang-codereviews
https://golang.org/cl/71030043
1) Move StateHijacked callback earlier, to make it
panic-proof. A Hijack followed by a panic didn't previously
result in ConnState getting fired for StateHijacked. Move it
earlier, to the time of hijack.
2) Don't fire StateActive unless any bytes were read off the
wire while waiting for a request. This means we don't
transition from New or Idle to Active if the client
disconnects or times out. This was documented before, but not
implemented properly.
This CL is required for an pending fix for Issue 7264
LGTM=josharian
R=josharian
CC=golang-codereviews
https://golang.org/cl/69860049
Unfortunately FreeBSD 10 has changed its syscall arguments for
some reasons but as per request at golang-dev this CL does not
generate some structures, syscall numbers and constants as
compatible to FreeBSD 10 as follows:
Structure: Stat_t, IfData, IfMsghdr are based on 8-STABLE
Syscall number: Capsicum API is based on 9-STABLE
Constant: IFT_CARP, SIOCAIFADDR, SIOCSIFPHYADDR are based on 9-STABLE
Update #7193
FreeBSD 10 breaking changes:
r205792: Rename st_*timespec fields to st_*tim for POSIX 2008
compliance.
http://svnweb.freebsd.org/base?view=revision&revision=205792
r254804: Restructure the mbuf pkthdr to make it fit for upcoming
capabilities and features.
http://svnweb.freebsd.org/base?view=revision&revision=254804
r255219: Change the cap_rights_t type from uint64_t to a structure
that we can extend in the future in a backward compatible (API and
ABI) way.
http://svnweb.freebsd.org/base?view=revision&revision=255219
LGTM=iant
R=golang-codereviews, rsc, minux.ma, gobot, iant
CC=golang-codereviews
https://golang.org/cl/56770044
In Go 1.2, closing a request body without reading to EOF
causes the underlying TCP connection to not be reused. This
client code following redirects was never updated when that
happened.
This was part of a previous CL but moved to its own CL at
Josh's request. Now with test too.
LGTM=josharian
R=josharian
CC=golang-codereviews
https://golang.org/cl/70800043
Currently a write error will cause future reads to return that same error.
However, there may have been extra information from a peer pending on
the read direction that is now unavailable.
This change splits the single connErr into errors for the read, write and
handshake. (Splitting off the handshake error is needed because both read
and write paths check the handshake error.)
Fixes#7414.
LGTM=bradfitz, r
R=golang-codereviews, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/69090044
The addition of Server.ConnState provides all the necessary
hooks to stop a Server gracefully, but StateNew previously
could fire concurrently with Serve exiting (as it does when
its net.Listener is closed). This previously meant one
couldn't use a WaitGroup incremented in the StateNew hook
along with calling Wait after Serve. Now you can.
Update #4674
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/70410044
Update #7338
The nil deref tests are currently failing on the *bsd/arm platforms. In an effort to avoid the build deteriorating further I would like to skip these tests on freebsd/arm and netbsd/arm.
LGTM=bradfitz, minux.ma
R=golang-codereviews, bradfitz, minux.ma
CC=golang-codereviews
https://golang.org/cl/69870045
cgocall.c: define the CBARGS macro for GOARCH_amd64p32. I don't think the value of this macro will ever be used under nacl/amd64p32 but it is required to compile even if cgo is not used.
hashmap.goc: amd64p32 uses 32bit words.
LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/69960044
This is a user error, but killing -1 kills everything, which
is a pretty bad failure mode.
Fixes#7434
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/70140043
While reviewing uses of the lower-level Client API in code, I found
that in many cases, code was using Client only because it needed a
timeout on the connection. DialWithDialer allows a timeout (and
other values) to be specified without resorting to the low-level API.
LGTM=r
R=golang-codereviews, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/68920045
Update #4674
This allows for all sorts of graceful shutdown policies,
without picking a policy (e.g. lameduck period) and without
adding lots of locking to the server core. That policy and
locking can be implemented outside of net/http now.
LGTM=adg
R=golang-codereviews, josharian, r, adg, dvyukov
CC=golang-codereviews
https://golang.org/cl/69260044
This CL replays the following one CL from the rsc-go13nacl repo.
This is the last replay CL: after this CL the main repo will have
everything the rsc-go13nacl repo did. Changes made to the main
repo after the rsc-go13nacl repo branched off probably mean that
NaCl doesn't actually work after this CL, but all the code is now moved
over and just needs to be redebugged.
---
cmd/6l, cmd/8l, cmd/ld: support for Native Client
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡khr
https://golang.org/cl/15750044
---
LGTM=bradfitz, dave, iant
R=dave, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/69040044
over multiple scans. Previously, the Go code assumed that DC was
synonymous with interleaved and AC with non-interleaved.
Fixes#6767.
The test files were generated with libjpeg's cjpeg program, version 9a,
with the following patch, since cjpeg is hard-coded to output
interleaved DC.
$ diff -u jpeg-9a*/jcparam.c
--- jpeg-9a-clean/jcparam.c 2013-07-01 21:13:28.000000000 +1000
+++ jpeg-9a/jcparam.c 2014-02-27 11:40:41.236889852 +1100
@@ -572,7 +572,7 @@
{
int ci;
- if (ncomps <= MAX_COMPS_IN_SCAN) {
+ if (0) {
/* Single interleaved DC scan */
scanptr->comps_in_scan = ncomps;
for (ci = 0; ci < ncomps; ci++)
@@ -610,7 +610,7 @@
(cinfo->jpeg_color_space == JCS_YCbCr ||
cinfo->jpeg_color_space == JCS_BG_YCC)) {
/* Custom script for YCC color images. */
- nscans = 10;
+ nscans = 14;
} else {
/* All-purpose script for other color spaces. */
if (ncomps > MAX_COMPS_IN_SCAN)
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/69000046
Before GC, we flush all the per-P allocation caches. Doing
stack shrinking mid-GC causes these caches to fill up. At the
end of gc, the sweepgen is incremented which causes all of the
data in these caches to be in a bad state (cached but not yet
swept).
Move the stack shrinking until after sweepgen is incremented,
so any caching that happens as part of shrinking is done with
already-swept data.
Reenable stack copying.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/69620043
No change to $GOROOT/src, misc formatting.
Nice side-effect: almost 3% faster runs because it's much faster to compute
line number differences in the generated output than the incoming source.
Benchmark run, best of 5 runs, before and after:
BenchmarkPrint 200 12347587 ns/op
BenchmarkPrint 200 11999061 ns/op
Fixes#4504.
LGTM=adonovan
R=golang-codereviews, adonovan
CC=golang-codereviews
https://golang.org/cl/69260045
This is the simple half of https://golang.org/cl/53560043/ with
a new benchmark. pongad is in the C+A files already.
benchmark old ns/op new ns/op delta
BenchmarkReaderWriteToOptimal 2054 825 -59.83%
Update #6373
LGTM=iant, gri
R=golang-codereviews, iant, gri
CC=golang-codereviews
https://golang.org/cl/69220046
This test currently deadlocks on dragonfly/386.
Update #7421
LGTM=minux.ma
R=golang-codereviews, minux.ma
CC=golang-codereviews
https://golang.org/cl/69380043
warning: src/pkg/runtime/mem_plan9.c:72 param declared and not used: n
src/pkg/runtime/mem_plan9.c:73 name not declared: nbytes
src/pkg/runtime/mem_plan9.c:73 bad in naddr: NAME nbytes<>+0(SB)
LGTM=minux.ma, bradfitz
R=khr, minux.ma, bradfitz
CC=golang-codereviews
https://golang.org/cl/69360043
On stack overflow, if all frames on the stack are
copyable, we copy the frames to a new stack twice
as large as the old one. During GC, if a G is using
less than 1/4 of its stack, copy the stack to a stack
half its size.
TODO
- Do something about C frames. When a C frame is in the
stack segment, it isn't copyable. We allocate a new segment
in this case.
- For idempotent C code, we can abort it, copy the stack,
then retry. I'm working on a separate CL for this.
- For other C code, we can raise the stackguard
to the lowest Go frame so the next call that Go frame
makes triggers a copy, which will then succeed.
- Pick a starting stack size?
The plan is that eventually we reach a point where the
stack contains only copyable frames.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/54650044
MCaches now hold a MSpan for each sizeclass which they have
exclusive access to allocate from, so no lock is needed.
Modifying the heap bitmaps also no longer requires a cas.
runtime.free gets more expensive. But we don't use it
much any more.
It's not much faster on 1 processor, but it's a lot
faster on multiple processors.
benchmark old ns/op new ns/op delta
BenchmarkSetTypeNoPtr1 24 23 -0.42%
BenchmarkSetTypeNoPtr2 33 34 +0.89%
BenchmarkSetTypePtr1 51 49 -3.72%
BenchmarkSetTypePtr2 55 54 -1.98%
benchmark old ns/op new ns/op delta
BenchmarkAllocation 52739 50770 -3.73%
BenchmarkAllocation-2 33957 34141 +0.54%
BenchmarkAllocation-3 33326 29015 -12.94%
BenchmarkAllocation-4 38105 25795 -32.31%
BenchmarkAllocation-5 68055 24409 -64.13%
BenchmarkAllocation-6 71544 23488 -67.17%
BenchmarkAllocation-7 68374 23041 -66.30%
BenchmarkAllocation-8 70117 20758 -70.40%
LGTM=rsc, dvyukov
R=dvyukov, bradfitz, khr, rsc
CC=golang-codereviews
https://golang.org/cl/46810043
Functions that "fit" on one line and were on one
line in the original source are not broken up into
two lines anymore simply because they contain a comment.
- Fine-tuned use of separating blanks after /*-style comments, so:
( /* extra blank after this comment */ )
(a int /* no extra blank after this comment*/)
- Factored out comment state (from printer state) into commentInfo.
- No impact on $GOROOT/src, misc formatting.
Fixes#5543.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/68630043
This partly addresses issue 6099 where a gofmt rewrite is behaving
unexpectedly because the provided rewrite term is not a valid expression
but is silently consumed anyway.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68920044
These are mistakes in the first big NaCl CL.
LGTM=minux.ma, iant
R=golang-codereviews, minux.ma, iant
CC=golang-codereviews
https://golang.org/cl/69200043
Switch nanotime to a monotonic clock on openbsd/386 and openbsd/amd64.
Also use a monotonic clock when for thrsleep, since the sleep duration
is based on the value returned from nanotime.
Update #6007
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68460044
For now we don't use CLOCK_MONOTONIC_FAST instead because
it's not supported on prior to 9-STABLE.
Update #6007
LGTM=minux.ma
R=golang-codereviews, minux.ma, bradfitz
CC=golang-codereviews
https://golang.org/cl/68690043
These previously reviewed CLs are present in this CL.
---
changeset: 18445:436bb084caed
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 09:50:34 2013 -0500
description:
runtime: assembly and system calls for Native Client x86-64
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡adg
https://golang.org/cl/15760044
---
changeset: 18448:90bd871b5994
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 09:51:36 2013 -0500
description:
runtime: amd64p32 and Native Client assembly bootstrap
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡khr
https://golang.org/cl/15820043
---
changeset: 18449:b011c3dc687e
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 09:51:58 2013 -0500
description:
math: amd64p32 assembly routines
These routines only manipulate float64 values,
so the amd64 and amd64p32 can share assembly.
The large number of files is symptomatic of a problem
with package path: it is a Go package structured like a C library.
But that will need to wait for another day.
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡bradfitz
https://golang.org/cl/15870043
---
changeset: 18450:43234f082eec
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 10:03:19 2013 -0500
description:
syscall: networking for Native Client
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡rsc
https://golang.org/cl/15780043
---
changeset: 18451:9c8d1d890aaa
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 10:03:34 2013 -0500
description:
runtime: assembly and system calls for Native Client x86-32
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡rsc
https://golang.org/cl/15800043
---
changeset: 18452:f90b1dd9228f
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 11:04:09 2013 -0500
description:
runtime: fix frame size for linux/amd64 runtime.raise
R≡rsc
https://golang.org/cl/24480043
---
changeset: 18445:436bb084caed
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 09:50:34 2013 -0500
description:
runtime: assembly and system calls for Native Client x86-64
See golang.org/s/go13nacl for design overview.
This CL is publicly visible but not CC'ed to golang-dev,
to avoid distracting from the preparation of the Go 1.2
release.
This CL and the others will be checked into my rsc-go13nacl
clone repo for now, and I will send CLs against the main
repo early in the Go 1.3 development.
R≡adg
https://golang.org/cl/15760044
---
changeset: 18455:53b06799a938
user: Russ Cox <rsc@golang.org>
date: Mon Nov 11 23:29:52 2013 -0500
description:
cmd/gc: add -nolocalimports flag
R≡dsymonds
https://golang.org/cl/24990043
---
changeset: 18456:24f64e1eaa8a
user: Russ Cox <rsc@golang.org>
date: Tue Nov 12 22:06:29 2013 -0500
description:
runtime: add comments for playback write
R≡adg
https://golang.org/cl/25190043
---
changeset: 18457:d1f615bbb6e4
user: Russ Cox <rsc@golang.org>
date: Wed Nov 13 17:03:52 2013 -0500
description:
runtime: write only to NaCl stdout, never to NaCl stderr
NaCl writes some other messages on standard error
that we would like to be able to squelch.
R≡adg
https://golang.org/cl/26240044
---
changeset: 18458:1f01be1a1dc2
tag: tip
user: Russ Cox <rsc@golang.org>
date: Wed Nov 13 19:45:16 2013 -0500
description:
runtime: remove apparent debugging dreg
Setting timens to 0 turns off fake time.
TBR≡adg
https://golang.org/cl/26400043
LGTM=bradfitz
R=dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/68730043
Solaris does not define syscall.{Mmap,Munmap}. Move the Mmap test to a new file and exclude solaris as discussed.
LGTM=aram
R=aram, mikioh.mikioh, iant
CC=golang-codereviews
https://golang.org/cl/68720043
See golang.org/s/go13nacl for design overview.
This CL is the mostly mechanical changes from rsc's Go 1.2 based NaCl branch, specifically 39cb35750369 to 500771b477cf from https://code.google.com/r/rsc-go13nacl. This CL does not include working NaCl support, there are probably two or three more large merges to come.
CL 15750044 is not included as it involves more invasive changes to the linker which will need to be merged separately.
The exact change lists included are
15050047: syscall: support for Native Client
15360044: syscall: unzip implementation for Native Client
15370044: syscall: Native Client SRPC implementation
15400047: cmd/dist, cmd/go, go/build, test: support for Native Client
15410048: runtime: support for Native Client
15410049: syscall: file descriptor table for Native Client
15410050: syscall: in-memory file system for Native Client
15440048: all: update +build lines for Native Client port
15540045: cmd/6g, cmd/8g, cmd/gc: support for Native Client
15570045: os: support for Native Client
15680044: crypto/..., hash/crc32, reflect, sync/atomic: support for amd64p32
15690044: net: support for Native Client
15690048: runtime: support for fake time like on Go Playground
15690051: build: disable various tests on Native Client
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/68150047
This CL adds a test that calls Mmap and Munmap through Syscall9
as the canary that detects assembly fragment breakage. For now
there is no package test that uses Syscall9 in the standard
library across all Unix-like systems.
Note that the package runtime owns its assembly fragments, so
this canary never works for runtime breakage.
LGTM=iant, bradfitz
R=iant, minux.ma, bradfitz
CC=golang-codereviews
https://golang.org/cl/61520049
These are only the new files, autogenerated files are in a
different CL to keep the size down.
LGTM=dave, minux.ma, jsing
R=golang-codereviews, dave, jsing, gobot, minux.ma, rsc, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/36000043
Update #3362
Also set a 30 second timeout, instead of relying on the
operating system's timeout, which if often but not always 3
minutes.
LGTM=crawshaw
R=rsc, crawshaw
CC=golang-codereviews
https://golang.org/cl/68330046
Currently an ECDHE handshake uses the client's curve preference. This
generally means that we use P-521. However, P-521's strength is
mismatched with the rest of the cipher suite in most cases and we have
a fast, constant-time implementation of P-256.
With this change, Go servers will use P-256 where the client supports
it although that can be overridden in the Config.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/66060043
Fatal must not be called from secondary goroutines.
Fixes#7401.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/67820047
Reinforce the guarantee that MSpan_EnsureSwept actually ensures that the span is swept.
I have not observed crashes related to this, but I do not see why it can't crash as well.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/67990043
Note that current z-files for linux/amd64,386,arm are based on 3.2 kernel.
LGTM=iant
R=golang-codereviews, dave, bradfitz, gobot, iant
CC=golang-codereviews
https://golang.org/cl/59160044
runfinqv is already defined the same way on line 271.
There may also be something to fix in compiler/linker wrt diagnostics.
Fixes#7375.
LGTM=bradfitz
R=golang-codereviews, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/67850044
Update #7347
When runtime.panic is called the *Panic is malloced from the heap. This can lead to a gc cycle while panicing which can make a bad situation worse.
It appears to be possible to stack allocate the Panic and avoid malloc'ing during a panic.
Ref: https://groups.google.com/d/topic/golang-dev/OfxqpklGkh0/discussion
LGTM=minux.ma, dvyukov, rsc
R=r, minux.ma, gobot, rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/66830043
This lays the groundwork for making Go robust when the system's
calendar time jumps around. All input values to the runtimeTimer
struct now use the runtime clock as a common reference point.
This affects net.Conn.Set[Read|Write]Deadline(), time.Sleep(),
time.Timer, etc. Under normal conditions, behavior is unchanged.
Each platform and architecture's implementation of runtime·nanotime()
should be modified to use a monotonic system clock when possible.
Platforms/architectures modified and tested with monotonic clock:
linux/x86 - clock_gettime(CLOCK_MONOTONIC)
Update #6007
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, alex.brainman, stephen.gutekanst, dave, rsc, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53010043
After "runtime: combine small NoScan allocations" finalizers
for small objects run more non deterministically.
TestRaceFin episodically fails on my darwin/amd64.
LGTM=khr
R=golang-codereviews, khr, dave
CC=golang-codereviews
https://golang.org/cl/56970043
As per request from minux in CL 61520049, this CL consolidates
existing test cases for Unix-like systems into one file except
Linux-specific credential test.
LGTM=bradfitz
R=iant, minux.ma, bradfitz
CC=golang-codereviews
https://golang.org/cl/67800044
crypto/tls has two functions for creating a client connection: Dial,
which most users are expected to use, and Client, which is the
lower-level API.
Dial does what you expect: it gives you a secure connection to the host
that you specify and the majority of users of crypto/tls appear to work
fine with it.
Client gives more control but needs more care. Specifically, if it
wasn't given a server name in the tls.Config then it didn't check that
the server's certificates match any hostname - because it doesn't have
one to check against. It was assumed that users of the low-level API
call VerifyHostname on the certificate themselves if they didn't supply
a hostname.
A review of the uses of Client both within Google and in a couple of
external libraries has shown that nearly all of them got this wrong.
Thus, this change enforces that either a ServerName or
InsecureSkipVerify is given. This does not affect tls.Dial.
See discussion at https://groups.google.com/d/msg/golang-nuts/4vnt7NdLvVU/b1SJ4u0ikb0J.
Fixes#7342.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/67010043
SetPanicOnFault allows recovery from unexpected memory faults.
This can be useful if you are using a memory-mapped file
or probing the address space of the current program.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/66590044
Package runtime's C functions written to be called from Go
started out written in C using carefully constructed argument
lists and the FLUSH macro to write a result back to memory.
For some functions, the appropriate parameter list ended up
being architecture-dependent due to differences in alignment,
so we added 'goc2c', which takes a .goc file containing Go func
declarations but C bodies, rewrites the Go func declaration to
equivalent C declarations for the target architecture, adds the
needed FLUSH statements, and writes out an equivalent C file.
That C file is compiled as part of package runtime.
Native Client's x86-64 support introduces the most complex
alignment rules yet, breaking many functions that could until
now be portably written in C. Using goc2c for those avoids the
breakage.
Separately, Keith's work on emitting stack information from
the C compiler would require the hand-written functions
to add #pragmas specifying how many arguments are result
parameters. Using goc2c for those avoids maintaining #pragmas.
For both reasons, use goc2c for as many Go-called C functions
as possible.
This CL is a replay of the bulk of CL 15400047 and CL 15790043,
both of which were reviewed as part of the NaCl port and are
checked in to the NaCl branch. This CL is part of bringing the
NaCl code into the main tree.
No new code here, just reformatting and occasional movement
into .h files.
LGTM=r
R=dave, alex.brainman, r
CC=golang-codereviews
https://golang.org/cl/65220044
Rename should fail when the directory doesn't match.
It will fix the newly introduced test from cmd/pack
on Plan 9.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/65270044
Try to prevent messages like this:
'./pack' file does not exist����������������������������������������������������������������������������������������������������
TBR=adonovan
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/66270043
[Repeat of CL 64100044, after 32-bit fix in CL 66170043.]
Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.
The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.
This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).
There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.
The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/65820044
Users of the low-level, Client function are frequenctly missing the
fact that, unless they pass a ServerName to the TLS connection then it
cannot verify the certificates against any name.
This change makes it clear that at least one of InsecureSkipVerify and
ServerName should always be set.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/65440043
IsNil isn't quite the same as == nil, as this snippet shows:
// http://play.golang.org/p/huomslDZgw
package main
import "fmt"
import "reflect"
func main() {
var i interface{}
v := reflect.ValueOf(i)
fmt.Println(v.IsValid(), i == nil)
fmt.Println(v.IsNil())
}
The fact that IsNil panics if you call it with an untyped nil
was not apparent. Verbiage added for clarity.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/65480043
Update #6853
Nothing reads the Plan 9 symbol table anymore.
The last holdout was 'go tool nm', but since being rewritten in Go
it uses the standard symbol table for the binary format
(ELF, Mach-O, PE) instead.
Removing the Plan 9 symbol table saves ~15% disk space
on most binaries.
Two supporting changes included in this CL:
debug/gosym: use Go 1.2 pclntab to synthesize func-only
symbol table when there is no Plan 9 symbol table
debug/elf, debug/macho, debug/pe: ignore final EOF from ReadAt
LGTM=r
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/65740045
This is a relatively minor change.
This does not result in changes to go.text/unicode/norm. The go.text
packages will therefore be relatively unaffected. It does make the
way for an upgrade to CLDR 24, though.
The tests of all.bash pass, as well as the tests in go.text after
this update.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/65400044
broke 32-bit builds
««« original CL description
cmd/gc, runtime: enable precisestack by default
Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.
The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.
This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).
There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.
The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.
LGTM=r
R=r
CC=golang-codereviews, iant, khr
https://golang.org/cl/64100044
»»»
TBR=r
CC=golang-codereviews
https://golang.org/cl/65230043
Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.
The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.
This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).
There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.
The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.
LGTM=r
R=r
CC=golang-codereviews, iant, khr
https://golang.org/cl/64100044
I have seen this cause leaks where not all objects in a sync.Pool
would be reclaimed during the sync package tests.
I found it while debugging the '0 of 100 finalized' failure we are
seeing on arm, but it seems not to be the root cause for that one.
LGTM=dave, dvyukov
R=golang-codereviews, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/64920044
Callers of md5.Sum should do so to avoid allocations, the example did not demonstate this property.
««« original CL description
crypto/md5: add example for Sum
LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/64820044
»»»
LGTM=minux.ma
R=r, minux.ma
CC=golang-codereviews
https://golang.org/cl/65180043
Add b.RunParallel function that captures parallel benchmark boilerplate:
creates worker goroutines, joins worker goroutines, distributes work
among them in an efficient way, auto-tunes grain size.
Fixes#7090.
R=bradfitz, iant, josharian, tracey.brendan, r, rsc, gobot
CC=golang-codereviews
https://golang.org/cl/57270043
Catch the error instead and return it to the user. Before this fix,
the template package panicked. Now you get:
template: bug11:1:14: executing "bug11" at <.PS>: dereference of nil pointer of type *string
Extended example at http://play.golang.org/p/uP6pCW3qKTFixes#7333.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/64150043
These should never be found in a bzip2 file but it does appear that
there's a buggy encoder that is producing them. Since the official
bzip2 handles this case, this change makes the Go code do likewise.
With this change, the code produces the same output as the official
bzip2 code on the invalid example given in the bug.
Fixes#7279.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/64010043
Rfork is not splitting the stack when creating a new thread,
so the parent and child are executing on the same stack.
However, if the parent returns and keeps executing before
the child can read the arguments from the parent stack,
the child will not see the right arguments. The solution
is to load the needed pieces from the parent stack into
register before INT $64.
Thanks to Russ Cox for the explanation.
LGTM=rsc
R=rsc
CC=ality, golang-codereviews
https://golang.org/cl/64140043
Changing the PC confuses gdb, because execution does not
continue where gdb expects it. Not changing the PC has the
potential to confuse a stack dump, but when running under gdb
it seems better to confuse a stack dump than to confuse gdb.
Fixes#6776.
LGTM=rsc
R=golang-codereviews, dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/49580044
