This change works around the "out of fixed registers"
issue with the Plan 9 C compiler on 386, introduced by
the Bits change to uint64 in CL 169060043.
The purpose of this CL is to be able to properly
follow the conversion of the Plan 9 runtime to Go
on the Plan 9 builders.
This CL could be reverted once the Go compilers will
be converted to Go.
Thanks to Nick Owens for investigating this issue.
LGTM=rsc
R=rsc
CC=austin, golang-codereviews, mischief
https://golang.org/cl/177860043
The SudoG used to sit on the stack, so it was cheap to allocated
and didn't need to be cleaned up when finished.
For the conversion to Go, we had to move sudog off the stack
for a few reasons, so we added a cache of recently used sudogs
to keep allocation cheap. But we didn't add any of the necessary
cleanup before adding a SudoG to the new cache, and so the cached
SudoGs had stale pointers inside them that have caused all sorts
of awful, hard to debug problems.
CL 155760043 made sure SudoG.elem is cleaned up.
CL 150520043 made sure SudoG.selectdone is cleaned up.
This CL makes sure SudoG.next, SudoG.prev, and SudoG.waitlink
are cleaned up. I should have done this when I did the other two
fields; instead I wasted a week tracking down a leak they caused.
A dangling SudoG.waitlink can point into a sudogcache list that
has been "forgotten" in order to let the GC collect it, but that
dangling .waitlink keeps the list from being collected.
And then the list holding the SudoG with the dangling waitlink
can find itself in the same situation, and so on. We end up
with lists of lists of unusable SudoGs that are still linked into
the object graph and never collected (given the right mix of
non-trivial selects and non-channel synchronization).
More details in golang.org/issue/9110.
Fixes#9110.
LGTM=r
R=r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/177870043
I just created that redirect, so we can change
it once the wiki moves.
LGTM=bradfitz, khr
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/177780043
The garbage collector is now written in Go.
There is plenty to clean up (just like on dev.cc).
all.bash passes on darwin/amd64, darwin/386, linux/amd64, linux/386.
TBR=rlh
R=austin, rlh, bradfitz
CC=golang-codereviews
https://golang.org/cl/173250043
* _sfloat dispatches to runtime._sfloat2 with the Go calling convention, so the seecond argument is a [15]uint32, not a *[15]uint32.
* adjust _sfloat2 to return the new pc in 68(R13) as expected.
LGTM=rsc
R=minux, austin, rsc
CC=golang-codereviews
https://golang.org/cl/174160043
It's rather unsporting of the kernel to give us a pointer to unaligned memory.
This fixes one crash, the next crash occurs in the soft float emulation.
LGTM=minux, rsc, austin
R=minux, rsc, austin
CC=golang-codereviews
https://golang.org/cl/177730043
warning: src/liblink/asm9.c:501 set and not used: bflag
warning: src/liblink/list9.c:259 format mismatch .5lux INT, arg 4
warning: src/liblink/list9.c:261 format mismatch .5lux INT, arg 3
warning: src/liblink/list9.c:319 more arguments than format VLONG
warning: src/liblink/obj9.c:222 set and not used: autoffset
LGTM=bradfitz, austin
R=rsc, bradfitz
CC=austin, golang-codereviews
https://golang.org/cl/175070043
The pretty printers for these make it hard to understand
what's actually in the fields of these structures. These
"ugly printers" show exactly what's in each field, which can
be useful for understanding and debugging code.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175780043
This is to reduce the delta between dev.cc and dev.garbage to just garbage collector changes.
These are the files that had merge conflicts and have been edited by hand:
malloc.go
mem_linux.go
mgc.go
os1_linux.go
proc1.go
panic1.go
runtime1.go
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/174180043
Now the only difference between dev.cc and dev.garbage
is the runtime conversion on the one side and the
garbage collection on the other. They both have the
same set of changes from default and dev.power64.
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/172570043
This is more complicated than the other enums because the D_*
enums are full of explicit initializers and repeated values.
This tries its best. (This will get much cleaner once we
tease these constants apart better.)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/166700043
Theses were very helpful in understanding the regions and
register selection when porting regopt to 9g. Add them to the
other compilers (and improve 9g's successor debug print).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174130043
I added several comments to the regopt-related structures when
porting it to 9g. Synchronize those comments back in to the
other compilers.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175720043
This adds registerization support to 9g equivalent to what the
other compilers have.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/174980043
None of the other compilers have a tag for this enum.
Cleaning all of this up to use proper types will happen after
the conversion.
LGTM=minux, rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/166690043
Previously, the 6g and 8g registerizers scanned for used
registers beyond the end of a region being considered for
registerization. This ancient artifact was copied from the C
compilers, where it was probably necessary to track implicitly
used registers. In the Go compilers it's harmless (because it
can only over-restrict the set of available registers), but no
longer necessary because the Go compilers correctly track
register use/set information. The consequences of this extra
scan were (at least) that 1) we would not consider allocating
the AX register if there was a deferproc call in the future
because deferproc uses AX as a return register, so we see the
use of AX, but don't track that AX is set by the CALL, and 2)
we could not consider allocating the DX register if there was
a MUL in the future because MUL implicitly sets DX and (thanks
to an abuse of copyu in this code) we would also consider DX
used.
This commit fixes these problems by nuking this code.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174110043
This was originally done to the C port in rev 17d3b45534b5 and
seemingly got lost during the conversion.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/167700043
Memory management was consolitated with the BSD ports, since
it was almost identical.
Assembly thunks are gone, being replaced by the new //go:linkname
feature.
This change supersedes CL 138390043 (runtime: convert solaris
netpoll to Go), which was previously reviewed and tested.
This change is only the first step, the port now builds,
but doesn't run. Binaries fail to exec:
ld.so.1: 6.out: fatal: 6.out: TLS requirement failure : TLS support is unavailable
Killed
This seems to happen because binaries don't link with libc.so
anymore. We will have to solve that in a different CL.
Also this change is just a rough translation of the original
C code, cleanup will come in a different CL.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=rsc
R=rsc, dave
CC=golang-codereviews, iant, khr, minux, r, rlh
https://golang.org/cl/174960043
Per private thread soliciting help. I realized part of this is
documented in several places, but we lacked a unifying
example.
LGTM=rsc
R=golang-codereviews
CC=adg, golang-codereviews, iant, rsc
https://golang.org/cl/171620043
For D_OREG addresses, store the used registers in regindex
instead of reguse because they're really part of addressing.
Add implicit register use/set for DUFFZERO/DUFFCOPY.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174050044
Scalararg and ptrarg are not "signal safe".
Go code filling them out can be interrupted by a signal,
and then the signal handler runs, and if it also ends up
in Go code that uses scalararg or ptrarg, now the old
values have been smashed.
For the pieces of code that do need to run in a signal handler,
we introduced onM_signalok, which is really just onM
except that the _signalok is meant to convey that the caller
asserts that scalarg and ptrarg will be restored to their old
values after the call (instead of the usual behavior, zeroing them).
Scalararg and ptrarg are also untyped and therefore error-prone.
Go code can always pass a closure instead of using scalararg
and ptrarg; they were only really necessary for C code.
And there's no more C code.
For all these reasons, delete scalararg and ptrarg, converting
the few remaining references to use closures.
Once those are gone, there is no need for a distinction between
onM and onM_signalok, so replace both with a single function
equivalent to the current onM_signalok (that is, it can be called
on any of the curg, g0, and gsignal stacks).
The name onM and the phrase 'm stack' are misnomers,
because on most system an M has two system stacks:
the main thread stack and the signal handling stack.
Correct the misnomer by naming the replacement function systemstack.
Fix a few references to "M stack" in code.
The main motivation for this change is to eliminate scalararg/ptrarg.
Rick and I have already seen them cause problems because
the calling sequence m.ptrarg[0] = p is a heap pointer assignment,
so it gets a write barrier. The write barrier also uses onM, so it has
all the same problems as if it were being invoked by a signal handler.
We worked around this by saving and restoring the old values
and by calling onM_signalok, but there's no point in keeping this nice
home for bugs around any longer.
This CL also changes funcline to return the file name as a result
instead of filling in a passed-in *string. (The *string signature is
left over from when the code was written in and called from C.)
That's arguably an unrelated change, except that once I had done
the ptrarg/scalararg/onM cleanup I started getting false positives
about the *string argument escaping (not allowed in package runtime).
The compiler is wrong, but the easiest fix is to write the code like
Go code instead of like C code. I am a bit worried that the compiler
is wrong because of some use of uninitialized memory in the escape
analysis. If that's the reason, it will go away when we convert the
compiler to Go. (And if not, we'll debug it the next time.)
LGTM=khr
R=r, khr
CC=austin, golang-codereviews, iant, rlh
https://golang.org/cl/174950043
Also include onM_signalok fix from issue 8995.
Fixes linux/arm build.
Fixes#8995.
LGTM=r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/168580043
This was recorded as an hg mv instead of an hg cp.
For now a C version is needed for the Go compiler.
TBR=r
CC=golang-codereviews
https://golang.org/cl/174020043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
vlrt.c was only called from C. Pure delete.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, austin
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/174860043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/174830044
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, daniel.morsing
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/172260043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/172250044
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, austin
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/172250043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
In a few cases, defs_$GOOS_$GOARCH.go already existed,
so the target here is defs1_$GOOS_$GOARCH.go.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/171490043
float.c held bit patterns for special float64 values,
hiding from the real uses. Rewrite Go code not to
refer to those values directly.
Convert library routines in runtime.c and string.c.
LGTM=r
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/170330043
Otherwise no system will get an 'ok' until they all do.
LGTM=r, dave
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/170320044
The main change is that #include "zasm_GOOS_GOARCH.h"
is now #include "go_asm.h" and/or #include "go_tls.h".
Also, because C StackGuard is now Go _StackGuard,
the assembly name changes from const_StackGuard to
const__StackGuard.
In asm_$GOARCH.s, add new function getg, formerly
implemented in C.
The renamed atomics now have Go wrappers, to get
escape analysis annotations right. Those wrappers
are in CL 174860043.
LGTM=r, aram
R=r, aram
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168510043
This code overused macros and could not be
converted automatically. Instead a new sigctxt
type had to be defined for each os/arch combination,
with a common (implicit) interface used by the
arch-specific signal handler code.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168500044
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168500043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, austin
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/167550043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/167540043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/166520043
Add missing write barrier when initializing state
for newly created goroutine. Add write barrier for
same slot when preempting a goroutine.
Disable write barrier during goroutine death,
because dopanic does pointer writes.
With concurrent mark enabled (not in this CL), all.bash passed once.
The second time, TestGoexitCrash-2 failed.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/167610043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
- Remove references to C compiler directories.
- Remove generation of special header files.
- Remove generation of Go source files from C declarations.
- Compile Go sources before rest of package (was after),
so that Go compiler can write go_asm.h for use in assembly.
- Move TLS information from cmd/dist (was embedding in output)
to src/runtime/go_tls.h, which it can be maintained directly.
LGTM=r
R=r, dave
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/172960043
If the linker finds the same name given a BSS and a non-BSS
symbol, the assumption is that the non-BSS symbol is the
true one, and the BSS symbol is just the best Go can do toward
an "extern" declaration. This has always been the case,
as long as the object files were read in the right order.
The old code worked when the BSS symbol is found before
the non-BSS symbol. This CL adds equivalent logic for when
the non-BSS symbol is found before the BSS symbol.
This comes up when Go must refer to symbols defined in
host object files.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/171480043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
Make gcToolchain.cc return an error (no C compiler!).
Adjust expectations of cgo, now that cgo does not write any C files
(no C compiler!).
For packages with .s files, invoke Go compiler with -asmhdr go_asm.h
so that assembly files can use it. This applies to all packages but is only
needed today by package runtime.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/171470043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
export.c, lex.c:
Add -asmhdr flag to write assembly header file with struct
field offsets and const values. cmd/dist used to construct this
file by interpreting output from the C compiler.
Generate it from the Go definitions instead.
Also, generate the form we need directly, instead of relying
on cmd/dist for reprocessing.
lex.c, obj.c:
If the C compiler accepted #pragma cgo_xxx, recognize
a directive //go:cgo_xxx instead. The effect is the same as
in the C compiler: accumulate text into a buffer and emit in the
output file, where the linker will find and use it.
lex.c, obj.c:
Accept //go:linkname to control the external symbol name
used for a particular top-level Go variable. This makes it
possible to refer to C symbol names but also symbols from
other packages. It has always been possible to do this from
C and assembly. To drive home the point that this should not
be done lightly, require import "unsafe" in any file containing
//go:linkname.
plive.c, reflect.c, subr.c:
Hard-code that interfaces contain only pointers.
This means code handling multiword values in the garbage
collector and the stack copier can be deleted instead of being
converted. This change is already present in the dev.garbage
branch.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/169360043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
We changed cgo to write the actual function wrappers in Go
for Go 1.4. The only code left in C output files was the definitions
for pointers to C data and the #pragma cgo directives.
Write both of those to Go outputs instead, using the new
compiler directives introduced in CL 169360043.
(Still generating C files in gccgo mode.)
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/169330045
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
Adjustments for changes made in CL 169360043.
This change is already present in the dev.garbage branch.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/167520044
Let's just do this up front.
This will break the build (here on the dev.cc branch).
The CLs that follow will take care of fixing it.
Leave behind cmd/cc/lexbody and cmd/cc/macbody for the assemblers.
They'll go away later.
LGTM=dave, r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/172170043
To turn concurrent gc on alter the if false in func gogc
currently at line 489 in malloc.go
LGTM=rsc
R=rsc
CC=golang-codereviews, rlh
https://golang.org/cl/172190043
This patch is based only on reading the code. I have not
tried to construct a test case.
Fixes#9077.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/172110043
Manifested as increased memory usage in a Google production system.
Not an unbounded leak, but can significantly increase the number
of sudogs allocated between garbage collections.
I checked all the other calls to acquireSudog.
This is the only one that was missing a releaseSudog.
LGTM=r, dneil
R=dneil, r
CC=golang-codereviews
https://golang.org/cl/169260043
These are being built into the runtime/cgo for every
operating system. It doesn't seem to matter, but
restore the Go 1.3 behavior anyway.
LGTM=r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/171290043
This was a mistake. The cmd/api tool
depends on an old version of go/types.
««« original CL description
cmd/api: use golang.org/x/... import paths
LGTM=bradfitz, rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/169000043
»»»
TBR=rsc, bradfitz
R=bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/169320043
This was a mistake; the cmd/api tool
depends on an old version of go/types.
««« original CL description
cmd/api: bump go.tools golden CL hash
TBR=bradfitz
R=rsc
CC=golang-codereviews
https://golang.org/cl/166380043
»»»
TBR=bradfitz, rsc
R=bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/167430043
New detection because of net/http now using TestMain.
Fixes#9033
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, rsc
https://golang.org/cl/170210043
Replace a bit-wise AND with a logical one. This happened to
work before because bany returns 0 or 1, but the intent here
is clearly logical (and this makes 5g match with 6g and 8g).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/172850043
This was missing from CL 167320043.
Happy to apply comments in a followup.
TBR to fix build.
TBR=r
CC=golang-codereviews
https://golang.org/cl/171260043
Moving so that new Go 1.4 pprof can use it.
The old 'GNU objdump workalike' mode for 'go tool objdump'
is now gone, as are the tests for that mode. It was used only
by pre-Go 1.4 pprof. You can still specify an address range on
the command line; you just get the same output format as
you do when dumping the entire binary (without an address
limitation).
LGTM=r
R=r
CC=golang-codereviews, iant
https://golang.org/cl/167320043
For OITAB nodes, 5g's naddr was setting the wrong etype and
failing to set the width of the resulting Addr.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/171220043
9g's naddr was missing assignments to a->width in several
cases, so the optimizer was getting bogus width information.
Add them.
This correct width information also lets us enable the width
check in gins for MOV*.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/167310043
The etype of references to strings was being incorrectly set
to TINT32 on all platforms. Change it to TSTRING. It seems
this doesn't matter for compilation, since x86 uses LEA
instructions to load string addresses and arm and power64
disassemble the string into its constituent pieces (with the
correct types), but it helps when debugging.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170100043
Stack bitmaps need to be scanned past any BitsDead entries.
Object bitmaps will not have any BitsDead in them (bitmap extraction stops at
the first BitsDead entry in makeheapobjbv). data/bss bitmaps also have no BitsDead entries.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168270043
For some reason lsof is now hanging on my workstation
without the -b (avoid blocking in the kernel) option.
Adding -b makes the test pass and shouldn't hurt.
I don't know how recent the -b option is. If the builders
are ok with it, it's probably ok.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/166220043
Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.
It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.
Not doing this causes faults when you set
StackFromSystem = 1
StackFaultOnFree = 1
The new check in gentraceback will catch future lapses.
The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.
This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.
LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, r
https://golang.org/cl/167060043
The new rules for split functions mean that we are exposed
to the common bug of a function that loops forever at EOF.
Pick these off by shutting down the scanner if too many
consecutive empty tokens are delivered.
Fixes#9020.
LGTM=rsc, adg
R=golang-codereviews, rsc, adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/169970043
Previously, mkvar treated, for example, 0(AX) the same as AX.
As a result, a move to an indirect address would be marked as
*setting* the register, rather than just using it, resulting
in unnecessary register moves. Fix this by not producing
variables for indirect addresses.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/164610043
The test intended to skip direct calls when creating
registerization variables was testing p->to.type instead of
p->to.name, so it always failed, causing regopt to create
unnecessary variables for these names.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/169110043
Now each C printf, Go print, or Go println is guaranteed
not to be interleaved with other calls of those functions.
This should help when debugging concurrent failures.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/169120043
- Some sequencing issues with stopping the first gc_m round
at the right place to set up correctly for the second round.
- atomicxor8 is not idempotent; avoid xor.
- Maintain BitsDead type bits correctly; see long comment added.
- Enable checkmark phase by default for now.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/171090043
So far all of our architectures have had at most 32 registers,
so we've been able to use entry 0 in the Bits uint32 array
directly as a register mask. Power64 has 64 registers, so
this converts Bits to a uint64 array so we can continue to use
entry 0 directly as a register mask on Power64.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/169060043
This adds an independent mark phase to the GC that can be used to
verify the the default concurrent mark phase has found all reachable
objects. It uses the upper 2 bits of the boundary nibble to encode
the mark leaving the lower bits to encode the boundary and the
normal mark bit.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/167130043
The check for unknown command line debug flags in gc was
incorrect: the loop over debugtab terminates when it reaches a
nil entry, but it was only reporting an error if the parser
had passed the last entry of debugtab (which it never did).
Fix this by reporting the usage error if the loop reaches a
nil entry.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/166110043
Print PC stored in target Prog* of branch instructions when
available instead of the offset stored in the branch
instruction. The offset tends to be wrong after code
transformations, so previously this led to confusing listings.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168980043
Previously, nilopt was disabled on power64x because it threw
away "seemly random segments of code." Indeed, excise on
power64x failed to preserve the link field, so it excised not
only the requested instruction but all following instructions
in the function. Fix excise to retain the link field while
otherwise zeroing the instruction.
This makes nilopt safe on power64x. It still fails
nilptr3.go's tests for removal of repeated nil checks because
those depend on also optimizing away repeated loads, which
doesn't currently happen on power64x.
LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/168120043
Previously, the flags argument to mallocgc was an int in Go,
but a uint32 in C. Change the Go type to use uint32 so these
agree. The largest flag value is 2 (and of course no flag
values are negative), so this won't change anything on little
endian architectures, but it matters on big endian.
LGTM=rsc
R=khr, rsc
CC=golang-codereviews
https://golang.org/cl/169920043
The GC info masks for slices and strings were changed in
commit caab29a25f68, but the reference masks used by
gcinfo_test for power64x hadn't caught up. Now they're
identical to amd64, so this CL fixes this test by combining
the reference masks for these platforms.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162620044
reflect/asm_power64x.s was missing changes made to other
platforms for stack maps. This CL ports those changes. With
this fix, the reflect test passes on power64x.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/170870043
fastrand1 depends on testing the high bit of its uint32 state.
For efficiency, all of the architectures implement this as a
sign bit test. However, on power64, fastrand1 was using a
64-bit sign test on the zero-extended 32-bit state. This
always failed, causing fastrand1 to have very short periods
and often decay to 0 and get stuck.
Fix this by using a 32-bit signed compare instead of a 64-bit
compare. This fixes various tests for the randomization of
select of map iteration.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/166990043
All three cases of clearfat were wrong on power64x.
The cases that handle 1032 bytes and up and 32 bytes and up
both use MOVDU (one directly generated in a loop and the other
via duffzero), which leaves the pointer register pointing at
the *last written* address. The generated code was not
accounting for this, so the byte fill loop was re-zeroing the
last zeroed dword, rather than the bytes following the last
zeroed dword. Fix this by simply adding an additional 8 byte
offset to the byte zeroing loop.
The case that handled under 32 bytes was also wrong. It
didn't update the pointer register at all, so the byte zeroing
loop was simply re-zeroing the beginning of region. Again,
the fix is to add an offset to the byte zeroing loop to
account for this.
LGTM=dave, bradfitz
R=rsc, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/168870043
Apparently I had already moved on to fixing another problem
when I submitted CL 169790043.
LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/165210043
No real problems found. Just lots of argument names that
didn't quite match up.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/169790043
This adds a test to runtime·check to ensure CAS of large
unsigned 32-bit numbers does not accidentally sign-extend its
arguments.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/162490044
Previously, the power64x runtime assembly was sloppy about
using sign-extending versus zero-extending moves of arguments
and return values. I think all of the cases that actually
mattered have been fixed in recent CLs; this CL fixes up the
few remaining mismatches.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162480043
This CL implements the many multiword write barriers by calling
writebarrierptr, so that only writebarrierptr needs the actual barrier.
In lieu of an actual barrier, writebarrierptr checks that the value
being copied is not a small non-zero integer. This is enough to
shake out bugs where the barrier is being called when it should not
(for non-pointer values). It also found a few tests in sync/atomic
that were being too clever.
This CL adds a write barrier for the memory moved during the
builtin copy function, which I forgot when inserting barriers for Go 1.4.
This CL re-enables some write barriers that were disabled for Go 1.4.
Those were disabled because it is possible to change the generated
code so that they are unnecessary most of the time, but we have not
changed the generated code yet. For safety they must be enabled.
None of this is terribly efficient. We are aiming for correct first.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/168770043
If you get a stack of PCs from Callers, it would be expected
that every PC is immediately after a call instruction, so to find
the line of the call, you look up the line for PC-1.
CL 163550043 now explicitly documents that.
The most common exception to this is the top-most return PC
on the stack, which is the entry address of the runtime.goexit
function. Subtracting 1 from that PC will end up in a different
function entirely.
To remove this special case, make the top-most return PC
goexit+PCQuantum and then implement goexit in assembly
so that the first instruction can be skipped.
Fixes#7690.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/170720043
This removes a bunch of ugly duplicate code.
The end goal is to factor the disassembly code
into cmd/internal/objfile too, so that pprof can use it,
but one step at a time.
LGTM=r, iant
R=r, alex.brainman, iant
CC=golang-codereviews
https://golang.org/cl/149400043
Originally traceback was only used for printing the stack
when an unexpected signal came in. In that case, the
initial PC is taken from the signal and should be used
unaltered. For the callers, the PC is the return address,
which might be on the line after the call; we subtract 1
to get to the CALL instruction.
Traceback is now used for a variety of things, and for
almost all of those the initial PC is a return address,
whether from getcallerpc, or gp->sched.pc, or gp->syscallpc.
In those cases, we need to subtract 1 from this initial PC,
but the traceback code had a hard rule "never subtract 1
from the initial PC", left over from the signal handling days.
Change gentraceback to take a flag that specifies whether
we are tracing a trap.
Change traceback to default to "starting with a return PC",
which is the overwhelmingly common case.
Add tracebacktrap, like traceback but starting with a trap PC.
Use tracebacktrap in signal handlers.
Fixes#7690.
LGTM=iant, r
R=r, iant
CC=golang-codereviews
https://golang.org/cl/167810044
Attempt to clear up confusion about how to turn
the PCs reported by Callers into the file and line
number people actually want.
Fixes#7690.
LGTM=r, chris.cs.guy
R=r, chris.cs.guy
CC=golang-codereviews
https://golang.org/cl/163550043
The goal here is to get the big-endian fixes so that
in some upcoming code movement for write barriers
I don't make them unmergeable.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/166890043
goprintf is a printf-like print for Go.
It is used in the code generated by 'defer print(...)' and 'go print(...)'.
Normally print(1, 2, 3) turns into
printint(1)
printint(2)
printint(3)
but defer and go need a single function call to give the runtime;
they give the runtime something like goprintf("%d%d%d", 1, 2, 3).
Variadic functions like goprintf cannot be described in the new
type information world, so we have to replace it.
Replace with a custom function, so that defer print(1, 2, 3) turns
into
defer func(a1, a2, a3 int) {
print(a1, a2, a3)
}(1, 2, 3)
(and then the print becomes three different printints as usual).
Fixes#8614.
LGTM=austin
R=austin
CC=golang-codereviews, r
https://golang.org/cl/159700043
I removed support for jumping between functions years ago,
as part of doing the instruction layout for each function separately.
Given that, it makes sense to treat labels as function-scoped.
This lets each function have its own 'loop' label, for example.
Makes the assembly much cleaner and removes the last
reason anyone would reach for the 123(PC) form instead.
Note that this is on the dev.power64 branch, but it changes all
the assemblers. The change will ship in Go 1.5 (perhaps after
being ported into the new assembler).
Came up as part of CL 167730043.
LGTM=r
R=r
CC=austin, dave, golang-codereviews, minux
https://golang.org/cl/159670043
In CL 160670043 the write function was changed
so a zero-length write is now allowed. This leads
the ExampleWriter_Init test to fail.
The reason is that Plan 9 preserves message
boundaries, while the os library expects systems
that don't preserve them. We have to ignore
zero-length writes so they will never turn into EOF.
This issue was previously discussed in CL 7406046.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/163510043
Power64 servers do not currently support sub-word size atomic
memory access, so atomicor8 uses word size atomic access.
However, previously atomicor8 made no attempt to align this
access, resulting in errors. Fix this by aligning the pointer
to a word boundary and shifting the value appropriately.
Since atomicor8 is used in GC, add a test to runtime·check to
make sure this doesn't break in the future.
This also fixes an incorrect branch label, an incorrectly
sized argument move, and adds argument names to help go vet.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/165820043
The "to" field was the penultimate argument to outgcode,
instead of the last argument, which swapped the third and
fourth operands. The argument order was correct in a.y, so
just swap the meaning of the arguments in outgcode. This
hadn't come up because we hadn't used these more obscure
operations in any hand-written assembly until now.
LGTM=rsc, dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/160690043
No easy way to test (would have to actually trigger some routing
events from kernel) but the code is clearly wrong as written.
If the header says there is a submessage, we need to at least
skip over its bytes, not just continue to the next iteration.
Fixes#8203.
LGTM=r
R=r
CC=golang-codereviews, mikioh.mikioh, p
https://golang.org/cl/164140044
get -u now checks that remote repo paths match the
ones predicted by the import paths: if you are get -u'ing
rsc.io/pdf, it has to be checked out from the right location.
This is important in case the rsc.io/pdf redirect changes.
In some cases, people have good reasons to use
non-standard remote repos. Add -f flag to allow that.
The f can stand for force or fork, as you see fit.
Fixes#8850.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/164120043
The wrapper code was being emitted before the stack
reservation, rather than after.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/161540043
Just to confirm the fix, by typing the follwing:
go test -run=TestLookupIPDeadline -dnsflood or
go test -run=TestLookupIPDeadline -dnsflood -tags netgo
Update #8602
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/166740043
Fix include paths that got moved in the great pkg/ rename. Add
missing runtime/arch_* files for power64. Port changes that
happened on default since branching to
runtime/{asm,atomic,sys_linux}_power64x.s (precise stacks,
calling convention change, various new and deleted functions.
Port struct renaming and fix some bugs in
runtime/defs_linux_power64.h.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/161450043
A recent commit lost the branch target in the really-big-stack
case of splitstack, causing an infinite loop stack preempt
case. Revive the branch target.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157790044
The ftab ends with a half functab record consisting only of
the 'entry' field followed by a uint32 giving the offset of
the next table. Previously, symtabinit assumed it could read
this uint32 as a uintptr. Since this is unsafe on big endian,
explicitly read the offset as a uint32.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157660043
Ports of platform-specific changes that happened on default
after dev.power64 forked (fixes for c2go, wrapper math fixes,
moved stackguard field, stackguard1 support, precise stacks).
Bug fixes (missing AMOVW in instruction table, correct
unsigned 32-bit remainder).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/164920044
Before this CL, if the system resolver does a very slow DNS
lookup for a particular host, all subsequent requests for that
host will hang waiting for that lookup to complete. That is
more or less expected when Dial is called with no deadline.
When Dial has a deadline, though, we can accumulate a large
number of goroutines waiting for that slow DNS lookup. Try to
avoid this problem by restarting the DNS lookup when it is
redone after a deadline is passed.
This CL also avoids creating an extra goroutine purely to
handle the deadline.
No test because we would have to simulate a slow DNS lookup
followed by a fast DNS lookup.
Fixes#8602.
LGTM=bradfitz
R=bradfitz, mikioh.mikioh
CC=golang-codereviews, r, rsc
https://golang.org/cl/154610044
The compatibility guideline needs to be clear about this even
though it means adding a clause that was not there from the
beginning. It has always been understood, so this isn't really
a change in policy, just in its expression.
LGTM=bradfitz, gri, rsc
R=golang-codereviews, bradfitz, gri, rsc
CC=golang-codereviews
https://golang.org/cl/162060043
Routines and logic to preform a concurrent stack scan of go-routines.
This CL excersizes most of the functionality needed. The
major exception being that it does not scan running goroutines.
After doing the scans it relies on a STW to finish the GC, including
rescanning the stacks. It is intended to achieve correctness,
performance will follow.
LGTM=rsc
R=golang-codereviews, rsc
CC=dvyukov, golang-codereviews
https://golang.org/cl/156580043
We force runtime.GC before WriteHeapProfile with -test.heapprofile.
Make it possible to do the same with the HTTP interface.
Some servers only run a GC every few minutes.
On such servers, the heap profile will be a few minutes stale,
which may be too old to be useful.
Requested by private mail.
LGTM=dvyukov
R=dvyukov
CC=golang-codereviews
https://golang.org/cl/161990043
In theory both of these lines encode the same three fields:
a,,c
a,"",c
However, Postgres defines that when importing CSV, the unquoted
version is treated as NULL (missing), while the quoted version is
treated as a string value (empty string). If the middle field is supposed to
be an integer value, the first line can be imported (NULL is okay), but
the second line cannot (empty string is not).
Postgres's import command (COPY FROM) has an option to force
the unquoted empty to be interpreted as a string but it does not
have an option to force the quoted empty to be interpreted as a NULL.
From http://www.postgresql.org/docs/9.0/static/sql-copy.html:
The CSV format has no standard way to distinguish a NULL
value from an empty string. PostgreSQL's COPY handles this
by quoting. A NULL is output as the NULL parameter string
and is not quoted, while a non-NULL value matching the NULL
parameter string is quoted. For example, with the default
settings, a NULL is written as an unquoted empty string,
while an empty string data value is written with double
quotes (""). Reading values follows similar rules. You can
use FORCE_NOT_NULL to prevent NULL input comparisons for
specific columns.
Therefore printing the unquoted empty is more flexible for
imports into Postgres than printing the quoted empty.
In addition to making the output more useful with Postgres, not
quoting empty strings makes the output smaller and easier to read.
It also matches the behavior of Microsoft Excel and Google Drive.
Since we are here and making concessions for Postgres, handle this
case too (again quoting the Postgres docs):
Because backslash is not a special character in the CSV
format, \., the end-of-data marker, could also appear as a
data value. To avoid any misinterpretation, a \. data value
appearing as a lone entry on a line is automatically quoted
on output, and on input, if quoted, is not interpreted as
the end-of-data marker. If you are loading a file created by
another application that has a single unquoted column and
might have a value of \., you might need to quote that value
in the input file.
Fixes#7586.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/164760043
The changes got rid of the problems we were seeing.
We suspect the pushcnt field has a race.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/159330043
Also updated defs3_linux.go but had to manually edit defs_linux_power64le.h. Will regenerate the file when cgo is working natively on ppc64.
LGTM=austin
R=rsc, austin
CC=golang-codereviews
https://golang.org/cl/158360043
go_bootstrap was panicking during runtime initialization
(under runtime.main) because Defer objects were being
prematurely GC'd. This happened because of an incorrect
change to runtime·unrollgcprog_m to make it endian-agnostic
during the conversion of runtime bitmaps to byte arrays.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/161960044
This brings dev.power64 up-to-date with the current tip of
default. go_bootstrap is still panicking with a bad defer
when initializing the runtime (even on amd64).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/152570049
The earlier dev.power64 merge missed the port of
runtime/noasm.goc to runtime/noasm_arm.go. This CL fixes this
by moving noasm_arm.go to noasm.go and adding a +build to
share the file between arm and power64.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/158350043
This also removes pkg/runtime/traceback_lr.c, which was ported
to Go in an earlier commit and then moved to
runtime/traceback.go.
Reviewer: rsc@golang.org
rsc: LGTM
Pool memory was only being released during the first GC after the first Put.
Put assumes that p.local != nil means p is on the allPools list.
poolCleanup (called during each GC) removed each pool from allPools
but did not clear p.local, so each pool was cleared by exactly one GC
and then never cleared again.
This bug was introduced late in the Go 1.3 release cycle.
Fixes#8979.
LGTM=rsc
R=golang-codereviews, bradfitz, r, rsc
CC=golang-codereviews, khr
https://golang.org/cl/162980043
Fixes#8348.
Trying to work around clang's dodgy support for .arch by reverting to the external assembler didn't work out so well. Minux had a much better solution to encode the instructions we need as .word directives which avoids .arch altogether.
I've confirmed with gdb that this form produces the expected machine code
Dump of assembler code for function crosscall_arm1:
0x00000000 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
0x00000004 <+4>: mov r4, r0
0x00000008 <+8>: mov r5, r1
0x0000000c <+12>: mov r0, r2
0x00000010 <+16>: blx r5
0x00000014 <+20>: blx r4
0x00000018 <+24>: pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, pc}
There is another compilation failure that blocks building Go with clang on arm
# ../misc/cgo/test
# _/home/dfc/go/misc/cgo/test
/tmp/--407b12.s: Assembler messages:
/tmp/--407b12.s:59: Error: selected processor does not support ARM mode `blx r0'
clang: error: assembler command failed with exit code 1 (use -v to see invocation)
FAIL _/home/dfc/go/misc/cgo/test [build failed]
I'll open a new issue for that
LGTM=iant
R=iant, minux
CC=golang-codereviews
https://golang.org/cl/158180047
Partial undo, changes to ldelf.c retained.
Some platforms are still not working even with the integrated assembler disabled, will have to find another solution.
««« original CL description
cmd/cgo: disable clang's integrated assembler
Fixes#8348.
Clang's internal assembler (introduced by default in clang 3.4) understands the .arch directive, but doesn't change the default value of -march. This causes the build to fail when we use BLX (armv5 and above) when clang is compiled for the default armv4t architecture (which appears to be the default on all the distros I've used).
This is probably a clang bug, so work around it for the time being by disabling the integrated assembler when compiling the cgo assembly shim.
This CL also includes a small change to ldelf.c which was required as clang 3.4 and above generate more weird symtab entries.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/156430044
»»»
LGTM=minux
R=iant, minux
CC=golang-codereviews
https://golang.org/cl/162880044
Get rid of gocputicks(), it is no longer used.
LGTM=bradfitz, dave
R=golang-codereviews, bradfitz, dave, minux
CC=golang-codereviews
https://golang.org/cl/161110044
This brings cmd/gc in line with the spec on this question.
It might break existing code, but that code was not conformant
with the spec.
Credit to Rémy for finding the broken code.
Fixes#6366.
LGTM=r
R=golang-codereviews, r
CC=adonovan, golang-codereviews, gri
https://golang.org/cl/129550043
Allows parsing some file formats that assign special
meaning to which stream data is found in.
Will do the same for compress/bzip2 once this is
reviewed and submitted.
Fixes#6486.
LGTM=nigeltao
R=nigeltao, dan.kortschak
CC=adg, bradfitz, golang-codereviews, r
https://golang.org/cl/159120044
Fixes#8348.
Clang's internal assembler (introduced by default in clang 3.4) understands the .arch directive, but doesn't change the default value of -march. This causes the build to fail when we use BLX (armv5 and above) when clang is compiled for the default armv4t architecture (which appears to be the default on all the distros I've used).
This is probably a clang bug, so work around it for the time being by disabling the integrated assembler when compiling the cgo assembly shim.
This CL also includes a small change to ldelf.c which was required as clang 3.4 and above generate more weird symtab entries.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/156430044
It has been failing periodically on Solaris/x64.
Change blockevent so it always records an event if we called
SetBlockProfileRate(1), even if the time delta is negative or zero.
Hopefully this will fix the test on Solaris.
Caveat: I don't actually know what the Solaris problem is, this
is just an educated guess.
LGTM=dave
R=dvyukov, dave
CC=golang-codereviews
https://golang.org/cl/159150043
Russ Cox pointed out that environment strings are not
required to be nil-terminated on Plan 9.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/159130044
Since CL 104570043 and 112720043, we are using the
nsec system call instead of /dev/bintime on Plan 9.
LGTM=rsc
R=rsc
CC=aram, golang-codereviews
https://golang.org/cl/155590043
Shell scripts depend on the old behavior too often.
It's too late to make this change.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/161890044
This test was failing but did not break the build because it
was not run when -test.short was used.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/157150043
I came across this while debugging a GC problem in gccgo.
There is code in assignTo and cvtT2I that handles assignment
to all interface values. It allocates an empty interface even
if the real type is a non-empty interface. The fields are
then set for a non-empty interface, but the memory is recorded
as holding an empty interface. This means that the GC has
incorrect information.
This is extremely unlikely to fail, because the code in the GC
that handles empty interfaces looks like this:
obj = nil;
typ = eface->type;
if(typ != nil) {
if(!(typ->kind&KindDirectIface) || !(typ->kind&KindNoPointers))
obj = eface->data;
In the current runtime the condition is always true--if
KindDirectIface is set, then KindNoPointers is clear--and we
always want to set obj = eface->data. So the question is what
happens when we incorrectly store a non-empty interface value
in memory marked as an empty interface. In that case
eface->type will not be a *rtype as we expect, but will
instead be a pointer to an Itab. We are going to use this
pointer to look at a *rtype kind field. The *rtype struct
starts out like this:
type rtype struct {
size uintptr
hash uint32 // hash of type; avoids computation in hash tables
_ uint8 // unused/padding
align uint8 // alignment of variable with this type
fieldAlign uint8 // alignment of struct field with this type
kind uint8 // enumeration for C
An Itab always has at least two pointers, so on a
little-endian 64-bit system the kind field will be the high
byte of the second pointer. This will normally be zero, so
the test of typ->kind will succeed, which is what we want.
On a 32-bit system it might be possible to construct a failing
case by somehow getting the Itab for an interface with one
method to be immediately followed by a word that is all ones.
The effect would be that the test would sometimes fail and the
GC would not mark obj, leading to an invalid dangling
pointer. I have not tried to construct this test.
I noticed this in gccgo, where this error is much more likely
to cause trouble for a rather random reason: gccgo uses a
different layout of rtype, and in gccgo the kind field happens
to be the low byte of a pointer, not the high byte.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/155450044
The stack blowout can no longer happen,
but we can still test that too-complex regexps
are rejected.
Replacement for CL 162770043.
LGTM=iant, r
R=r, iant
CC=bradfitz, golang-codereviews
https://golang.org/cl/162860043
This is already tested by TestRE2Exhaustive, but the build has
not broken because that test is not run when using -test.short.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/155580043
https://golang.org/cl/152700045/ made it possible for struct literals assigned to globals to use <N> as the RHS. Normally, this is to zero out variables on first use. Because globals are already zero (or their linker initialized value), we just ignored this.
Now that <N> can occur from non-initialization code, we need to emit this code. We don't use <N> for initialization of globals any more, so this shouldn't cause any excessive zeroing.
Fixes#8961.
LGTM=rsc
R=golang-codereviews, rsc
CC=bradfitz, golang-codereviews
https://golang.org/cl/154540044
As we did with encoding, provide a trivial byte reader for
faster decoding. We can also reduce some of the copying
by doing the allocation all at once using a slightly different
interface from byte buffers.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 13368 12902 -3.49%
BenchmarkEndToEndByteBuffer 5969 5642 -5.48%
BenchmarkEndToEndSliceByteBuffer 479485 470798 -1.81%
BenchmarkEncodeComplex128Slice 92367 92201 -0.18%
BenchmarkEncodeFloat64Slice 39990 38960 -2.58%
BenchmarkEncodeInt32Slice 30510 27938 -8.43%
BenchmarkEncodeStringSlice 33753 33365 -1.15%
BenchmarkDecodeComplex128Slice 232278 196704 -15.32%
BenchmarkDecodeFloat64Slice 150258 128191 -14.69%
BenchmarkDecodeInt32Slice 133806 115748 -13.50%
BenchmarkDecodeStringSlice 335117 300534 -10.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154360049
This adds a Reset() to compress/flate's decompressor and plumbs that through
to compress/zlib and compress/gzip's Readers so callers can avoid large
allocations when performing many inflate operations. In particular this
preserves the allocation of the decompressor.hist buffer, which is 32kb and
overwritten as needed while inflating.
On the benchmark described in issue 6317, produces the following speedup on
my 2.3ghz Intel Core i7 MBP with go version devel +6b696a34e0af Sun Aug 03
15:14:59 2014 -0700 darwin/amd64:
blocked.text w/out patch vs blocked.text w/ patch:
benchmark old ns/op new ns/op delta
BenchmarkGunzip 8371577533 7927917687 -5.30%
benchmark old allocs new allocs delta
BenchmarkGunzip 176818 148519 -16.00%
benchmark old bytes new bytes delta
BenchmarkGunzip 292184936 12739528 -95.64%
flat.text vs blocked.text w/patch:
benchmark old ns/op new ns/op delta
BenchmarkGunzip 7939447827 7927917687 -0.15%
benchmark old allocs new allocs delta
BenchmarkGunzip 90702 148519 +63.74%
benchmark old bytes new bytes delta
BenchmarkGunzip 9959528 12739528 +27.91%
Similar speedups to those bradfitz saw in https://golang.org/cl/13416045.
Fixes#6317.
Fixes#7950.
LGTM=nigeltao
R=golang-codereviews, bradfitz, dan.kortschak, adg, nigeltao, jamesr
CC=golang-codereviews
https://golang.org/cl/97140043
This is a day 1 error in the flag package: It did not check
that a flag was set at most once on the command line.
Because user-defined flags may have more general
properties, the check applies only to the standard flag
types in this package: bool, string, etc.
Fixes#8960.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/156390043
select {
case <- c:
case <- c:
}
In this case, c.recvq lists two SudoGs which have the same G.
So we can't use the G as the key to dequeue the correct SudoG,
as that key is ambiguous. Dequeueing the wrong SudoG ends up
freeing a SudoG that is still in c.recvq.
The fix is to use the actual SudoG pointer as the key.
LGTM=dvyukov
R=rsc, bradfitz, dvyukov, khr
CC=austin, golang-codereviews
https://golang.org/cl/159040043
Simple bug in argument processing: The final arg may
be the pipeline value, in which case it gets bound to the
fixed argument section. The code got that wrong. Easy
to fix.
Fixes#8950.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/161750043
Bytes buffers have more API and are a little slower. Since appending
is a key part of the path in encode, using a faster implementation
speeds things up measurably.
The couple of positive swings are likely garbage-collection related
since memory allocation looks different in the benchmark now.
I am not concerned by them.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6620 6388 -3.50%
BenchmarkEndToEndByteBuffer 3548 3600 +1.47%
BenchmarkEndToEndSliceByteBuffer 336678 367980 +9.30%
BenchmarkEncodeComplex128Slice 78199 71297 -8.83%
BenchmarkEncodeFloat64Slice 37731 32258 -14.51%
BenchmarkEncodeInt32Slice 26780 22977 -14.20%
BenchmarkEncodeStringSlice 35882 26492 -26.17%
BenchmarkDecodeComplex128Slice 194819 185126 -4.98%
BenchmarkDecodeFloat64Slice 120538 120102 -0.36%
BenchmarkDecodeInt32Slice 106442 107275 +0.78%
BenchmarkDecodeStringSlice 272902 269866 -1.11%
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/160990043
Use go generate to write better loops for decoding arrays,
just as we did for encoding. It doesn't help as much,
relatively speaking, but it's still noticeable.
benchmark old ns/op new ns/op delta
BenchmarkDecodeComplex128Slice 202348 184529 -8.81%
BenchmarkDecodeFloat64Slice 135800 120979 -10.91%
BenchmarkDecodeInt32Slice 121200 105149 -13.24%
BenchmarkDecodeStringSlice 288129 278214 -3.44%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154420044
Don't use cmd/pprof as it is not necessary installed
and does not work on nacl and plan9.
Instead just look at the raw profile.
LGTM=crawshaw, rsc
R=golang-codereviews, crawshaw, 0intro, rsc
CC=golang-codereviews
https://golang.org/cl/159010043
Better to avoid the memory loads and just use immediate constants.
This especially applies to zeroing, which was being done by
copying zeros from elsewhere in the binary, even if the value
was going to be completely initialized with non-zero values.
The zero writes were optimized away but the zero loads from
the data segment were not.
LGTM=r
R=r, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/152700045
Replace i < 0 || i >= x with uint(i) >= uint(x).
Shorten a few other code sequences.
Move the kind bits to the bottom of the flag word, to avoid shifts.
LGTM=r
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/159020043
We borrow a trick from the fmt package and avoid reflection
to walk the elements when possible. We could push further with
unsafe (and we may) but this is a good start.
Decode can benefit similarly; it will be done separately.
Use go generate (engen.go) to produce the helper functions
(enc_helpers.go).
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6593 6482 -1.68%
BenchmarkEndToEndByteBuffer 3662 3684 +0.60%
BenchmarkEndToEndSliceByteBuffer 350306 351693 +0.40%
BenchmarkComplex128Slice 96347 80045 -16.92%
BenchmarkInt32Slice 42484 26008 -38.78%
BenchmarkFloat64Slice 51143 36265 -29.09%
BenchmarkStringSlice 53402 35077 -34.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/156310043
gogo called from GC is okay
for the same reasons that
gogo called from System or ExternalCode is okay.
All three are fake stack traces.
Fixes#8408.
LGTM=dvyukov, r
R=r, dvyukov
CC=golang-codereviews
https://golang.org/cl/152580043
Dmitriy believes this broke Windows.
It looks like build.golang.org stopped before that,
but it's worth a shot.
««« original CL description
runtime: make pprof a little nicer
Update #8942
This does not fully address issue 8942 but it does make
the profiles much more useful, until that issue can be
fixed completely.
LGTM=dvyukov
R=r, dvyukov
CC=golang-codereviews
https://golang.org/cl/159990043
»»»
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/160030043
hg was unable to create a CL on the code review server for this,
so I am submitting the merge by hand.
The only manual edits are in mgc0.c, to reapply the
removal of cached/ncached to the new code.
It cannot run 'go tool pprof'. There is no guarantee that's installed.
It needs to build a temporary pprof binary and run that.
It also needs to skip the test on systems that can't build and
run binaries, namely android and nacl.
See src/cmd/nm/nm_test.go's TestNM for a template.
Update #8867
Status: Accepted
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/153710043
Update #8942
This does not fully address issue 8942 but it does make
the profiles much more useful, until that issue can be
fixed completely.
LGTM=dvyukov
R=r, dvyukov
CC=golang-codereviews
https://golang.org/cl/159990043
There are 3 issues:
1. Skip argument of callers is off by 3,
so that all allocations are deep inside of memory profiler.
2. Memory profiling statistics are not updated after runtime.GC.
3. Testing package does not update memory profiling statistics
before capturing the profile.
Also add an end-to-end test.
Fixes#8867.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/148710043
Both of these forms can avoid writing to the base pointer in x
(in the slice, always, and in the append, most of the time).
For Go 1.5, will need to change the compilation of x = x[0:y]
to avoid writing to the base pointer, so that the elision is safe,
and will need to change the compilation of x = append(x, ...)
to write to the base pointer (through a barrier) only when
growing the underlying array, so that the general elision is safe.
For Go 1.4, elide the write barrier always, a change that should
have equivalent performance characteristics but is much
simpler and therefore safer.
benchmark old ns/op new ns/op delta
BenchmarkBinaryTree17 3910526122 3918802545 +0.21%
BenchmarkFannkuch11 3747650699 3732600693 -0.40%
BenchmarkFmtFprintfEmpty 106 98.7 -6.89%
BenchmarkFmtFprintfString 280 269 -3.93%
BenchmarkFmtFprintfInt 296 282 -4.73%
BenchmarkFmtFprintfIntInt 467 470 +0.64%
BenchmarkFmtFprintfPrefixedInt 418 398 -4.78%
BenchmarkFmtFprintfFloat 574 535 -6.79%
BenchmarkFmtManyArgs 1768 1818 +2.83%
BenchmarkGobDecode 14916799 14925182 +0.06%
BenchmarkGobEncode 14110076 13358298 -5.33%
BenchmarkGzip 546609795 542630402 -0.73%
BenchmarkGunzip 136270657 136496277 +0.17%
BenchmarkHTTPClientServer 126574 125245 -1.05%
BenchmarkJSONEncode 30006238 27862354 -7.14%
BenchmarkJSONDecode 106020889 102664600 -3.17%
BenchmarkMandelbrot200 5793550 5818320 +0.43%
BenchmarkGoParse 5437608 5463962 +0.48%
BenchmarkRegexpMatchEasy0_32 192 179 -6.77%
BenchmarkRegexpMatchEasy0_1K 462 460 -0.43%
BenchmarkRegexpMatchEasy1_32 168 153 -8.93%
BenchmarkRegexpMatchEasy1_1K 1420 1280 -9.86%
BenchmarkRegexpMatchMedium_32 338 286 -15.38%
BenchmarkRegexpMatchMedium_1K 107435 98027 -8.76%
BenchmarkRegexpMatchHard_32 5941 4846 -18.43%
BenchmarkRegexpMatchHard_1K 185965 153830 -17.28%
BenchmarkRevcomp 795497458 798447829 +0.37%
BenchmarkTemplate 132091559 134938425 +2.16%
BenchmarkTimeParse 604 608 +0.66%
BenchmarkTimeFormat 551 548 -0.54%
LGTM=r
R=r, dave
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/159960043
A new attack on CBC padding in SSLv3 was released yesterday[1]. Go only
supports SSLv3 as a server, not as a client. An easy fix is to change
the default minimum version to TLS 1.0 but that seems a little much
this late in the 1.4 process as it may break some things.
Thus this patch adds server support for TLS_FALLBACK_SCSV[2] -- a
mechanism for solving the fallback problem overall. Chrome has
implemented this since February and Google has urged others to do so in
light of yesterday's news.
With this change, clients can indicate that they are doing a fallback
connection and Go servers will be able to correctly reject them.
[1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
[2] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157090043
Among other things, *x = T{} does not need a write barrier.
The changes here avoid an unnecessary copy even when
no pointers are involved, so it may have larger effects.
In 6g and 8g, avoid manually repeated STOSQ in favor of
writing explicit MOVs, under the theory that the MOVs
should have fewer dependencies and pipeline better.
Benchmarks compare best of 5 on a 2012 MacBook Pro Core i5
with TurboBoost disabled. Most improvements can be explained
by the changes in this CL.
The effect in Revcomp is real but harder to explain: none of
the instructions in the inner loop changed. I suspect loop
alignment but really have no idea.
benchmark old new delta
BenchmarkBinaryTree17 3809027371 3819907076 +0.29%
BenchmarkFannkuch11 3607547556 3686983012 +2.20%
BenchmarkFmtFprintfEmpty 118 103 -12.71%
BenchmarkFmtFprintfString 289 277 -4.15%
BenchmarkFmtFprintfInt 304 290 -4.61%
BenchmarkFmtFprintfIntInt 507 458 -9.66%
BenchmarkFmtFprintfPrefixedInt 425 408 -4.00%
BenchmarkFmtFprintfFloat 555 555 +0.00%
BenchmarkFmtManyArgs 1835 1733 -5.56%
BenchmarkGobDecode 14738209 14639331 -0.67%
BenchmarkGobEncode 14239039 13703571 -3.76%
BenchmarkGzip 538211054 538701315 +0.09%
BenchmarkGunzip 135430877 134818459 -0.45%
BenchmarkHTTPClientServer 116488 116618 +0.11%
BenchmarkJSONEncode 28923406 29294334 +1.28%
BenchmarkJSONDecode 105779820 104289543 -1.41%
BenchmarkMandelbrot200 5791758 5771964 -0.34%
BenchmarkGoParse 5376642 5310943 -1.22%
BenchmarkRegexpMatchEasy0_32 195 190 -2.56%
BenchmarkRegexpMatchEasy0_1K 477 455 -4.61%
BenchmarkRegexpMatchEasy1_32 170 165 -2.94%
BenchmarkRegexpMatchEasy1_1K 1410 1394 -1.13%
BenchmarkRegexpMatchMedium_32 336 329 -2.08%
BenchmarkRegexpMatchMedium_1K 108979 106328 -2.43%
BenchmarkRegexpMatchHard_32 5854 5821 -0.56%
BenchmarkRegexpMatchHard_1K 185089 182838 -1.22%
BenchmarkRevcomp 834920364 780202624 -6.55%
BenchmarkTemplate 137046937 129728756 -5.34%
BenchmarkTimeParse 600 594 -1.00%
BenchmarkTimeFormat 559 539 -3.58%
LGTM=r
R=r
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/157910047
A Go prototype can be used instead now, and the compiler
will do a better job than we will doing it by hand.
(We got it wrong in amd64p32, causing the current build
breakage.)
The auto-prototype-matching only applies to functions
without an explicit package path, so the TEXT lines for
reflectcall and callXX are s/runtime·/·/.
LGTM=khr
R=khr
CC=golang-codereviews, iant, r
https://golang.org/cl/153600043
The http package by default adds "Accept-Encoding: gzip" to outgoing
requests, unless it's a bad idea, or the user requested otherwise.
Only when the http package adds its own implicit Accept-Encoding header
does the http package also transparently un-gzip the response.
If the user requested part of a document (e.g. bytes 40 to 50), it appears
that Github/Varnish send:
range(gzip(content), 40, 50)
And not:
gzip(range(content, 40, 50))
The RFC 2616 set of replacements (with the purpose of
clarifying ambiguities since 1999) has an RFC about Range
requests (http://tools.ietf.org/html/rfc7233) but does not
mention the interaction with encodings.
Regardless of whether range(gzip(content)) or gzip(range(content)) is
correct, this change prevents the Go package from asking for gzip
in requests if we're also asking for Range, avoiding the issue.
If the user cared, they can do it themselves. But Go transparently
un-gzipping a fragment of gzip is never useful.
Fixes#8923
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/155420044
The assembler could give a better error, but this one
is good enough for now.
Fixes#8880.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/153610043
When the Import function in go/build encounters a directory
without any buildable Go source files, it returns a handy
NoGoError. Now if, instead it encounters multiple Go source files
from multiple packages, it returns a handy MultiplePackageError.
A new test for NoGoError and MultiplePackageError is also provided.
Fixes#8286.
LGTM=adg, rsc
R=bradfitz, rsc, adg
CC=golang-codereviews
https://golang.org/cl/155050043
The racewalk code was not updated for the new write barriers.
Make it more future-proof.
The new write barrier code assumed that +1 pointer would
be aligned properly for any type that might follow, but that's
not true on 32-bit systems where some types are 64-bit aligned.
The only system like that today is nacl/amd64p32.
Insert a dummy pointer so that the ambiguously typed
value is at +2 pointers, which is always max-aligned.
LGTM=r
R=r
CC=golang-codereviews, iant, khr
https://golang.org/cl/158890046
FieldByIndex never returns an invalid Value, so the validity
test can be avoided if the field is not indirect.
BenchmarkGobEncode 12768642 12424022 -2.70%
BenchmarkGobEncode 60.11 61.78 1.03x
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/158890045
includes undo of 22318cd31d7d and also:
- always use SetUnhandledExceptionFilter on windows-386;
- crash when receive EXCEPTION_BREAKPOINT in exception handler.
Fixes#8006.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/155360043
The inverse is defined whenever the element and the
modulus are relatively prime. The code already handles
this situation, but the spec does not.
Test that it does indeed work.
Fixes#8875
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/155010043
Assignments of 2-, 3-, and 4-word values were handled
by individual MOV instructions (and for scalars still are).
But if there are pointers involved, those assignments now
go through the write barrier routine. Before this CL, they
went to writebarrierfat, which calls memmove.
Memmove is too much overhead for these small
amounts of data.
Instead, call writebarrierfat{2,3,4}, which are specialized
for the specific amount of data being copied.
Today the write barrier does not care which words are
pointers, so size alone is enough to distinguish the cases.
If we keep these distinctions in Go 1.5 we will need to
expand them for all the pointer-vs-scalar possibilities,
so the current 3 functions will become 3+7+15 = 25,
still not a large burden (we deleted more morestack
functions than that when we dropped segmented stacks).
BenchmarkBinaryTree17 3250972583 3123910344 -3.91%
BenchmarkFannkuch11 3067605223 2964737839 -3.35%
BenchmarkFmtFprintfEmpty 101 96.0 -4.95%
BenchmarkFmtFprintfString 267 235 -11.99%
BenchmarkFmtFprintfInt 261 253 -3.07%
BenchmarkFmtFprintfIntInt 444 402 -9.46%
BenchmarkFmtFprintfPrefixedInt 374 346 -7.49%
BenchmarkFmtFprintfFloat 472 449 -4.87%
BenchmarkFmtManyArgs 1537 1476 -3.97%
BenchmarkGobDecode 13986528 12432985 -11.11%
BenchmarkGobEncode 13120323 12537420 -4.44%
BenchmarkGzip 451925758 437500578 -3.19%
BenchmarkGunzip 113267612 110053644 -2.84%
BenchmarkHTTPClientServer 103151 77100 -25.26%
BenchmarkJSONEncode 25002733 23435278 -6.27%
BenchmarkJSONDecode 94213717 82568789 -12.36%
BenchmarkMandelbrot200 4804246 4713070 -1.90%
BenchmarkGoParse 4646114 4379456 -5.74%
BenchmarkRegexpMatchEasy0_32 163 158 -3.07%
BenchmarkRegexpMatchEasy0_1K 433 391 -9.70%
BenchmarkRegexpMatchEasy1_32 154 138 -10.39%
BenchmarkRegexpMatchEasy1_1K 1481 1132 -23.57%
BenchmarkRegexpMatchMedium_32 282 270 -4.26%
BenchmarkRegexpMatchMedium_1K 92421 86149 -6.79%
BenchmarkRegexpMatchHard_32 5209 4718 -9.43%
BenchmarkRegexpMatchHard_1K 158141 147921 -6.46%
BenchmarkRevcomp 699818791 642222464 -8.23%
BenchmarkTemplate 132402383 108269713 -18.23%
BenchmarkTimeParse 509 478 -6.09%
BenchmarkTimeFormat 462 456 -1.30%
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/156200043
Comments lay out the concurrent GC algorithms.
This CL implements parts of the algorithm.
The acknowledgement code has been removed from this CL
LGTM=rsc, dvyukov
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/151540043
In [1] the behaviour of encoding/asn1 with respect to marshaling
optional integers was changed. Previously, a zero valued integer would
be omitted when marshaling. After the change, if a default value was
set then the integer would only be omitted if it was the default value.
This changed the behaviour of crypto/x509 because
Certificate.MaxPathLen has a default value of -1 and thus zero valued
MaxPathLens would no longer be omitted when marshaling. This is
arguably a bug-fix -- a value of zero for MaxPathLen is valid and
meaningful and now could be expressed. However it broke users
(including Docker) who were not setting MaxPathLen at all.
This change again causes a zero-valued MaxPathLen to be omitted and
introduces a ZeroMathPathLen member that indicates that, yes, one
really does want a zero. This is ugly, but we value not breaking users.
[1] https://code.google.com/p/go/source/detail?r=4218b3544610e8d9771b89126553177e32687adf
LGTM=rsc
R=rsc
CC=golang-codereviews, golang-dev
https://golang.org/cl/153420045
This error is returned by lib9p when removing a file
without parent. It should fix TestRemoveAllRace
when running on ramfs.
LGTM=bradfitz, aram
R=rsc, bradfitz, aram
CC=golang-codereviews, mischief
https://golang.org/cl/153410044
The code for a generated type is already generating an
unrolled GC bitmask. Rather than unrolling the the source
type bitmasks and copying them, just generate the required
bitmask directly. Don't mark it as an unrolled GC program,
since there is no need to do so.
Fixes#8917.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/156930044
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.
Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.
Fixes#8811.
Fixes#8856.
LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
gcc 4.9.1 generates pe sections with names longer then 8 charters.
From IMAGE_SECTION_HEADER definition:
Name
An 8-byte, null-padded UTF-8 string. There is no terminating null character
if the string is exactly eight characters long. For longer names, this
member contains a forward slash (/) followed by an ASCII representation
of a decimal number that is an offset into the string table.
Our current pe object file reader does not read string table when section
names starts with /. Do that, so (issue 8811 example)
c:\go\path\src\isssue8811>go build
# isssue8811
isssue8811/glfw(.text): isssue8811/glfw(/76): not defined
isssue8811/glfw(.text): undefined: isssue8811/glfw(/76)
becomes
c:\go\path\src\isssue8811>go build
# isssue8811
isssue8811/glfw(.text): isssue8811/glfw(.rdata$.refptr._glfwInitialized): not defined
isssue8811/glfw(.text): undefined: isssue8811/glfw(.rdata$.refptr._glfwInitialized)
Small progress to
Update #8811
LGTM=iant, jfrederich
R=golang-codereviews, iant, jfrederich
CC=golang-codereviews
https://golang.org/cl/154210044
I diffed the output of `nm -n gofmt' before and after this change,
and verified that all changes are correct and all corrupted symbol
names are fixed.
Fixes#8906.
LGTM=iant, cookieo9
R=golang-codereviews, iant, cookieo9
CC=golang-codereviews
https://golang.org/cl/159750043
https://golang.org/cl/153770043/ tried to fix the case where a
implicitly tagged Time, that happened to have the same tag as
GENERALIZEDTIME, shouldn't be parsed as a GENERALIZEDTIME.
It did so, mistakenly, by testing whether params.tag != nil. But
explicitly tagged values also have a non-nil tag and there the inner
tag actually does encode the type of the value.
This change instead tests whether the tag class is UNIVERSAL before
assuming that the tag contains type information.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/152380044
That was complete failure - builders are broken,
but original cl worked fine on my system.
I will need access to builders
to test this change properly.
««« original CL description
runtime: handle all windows exception
Fixes#8006.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/145150043
»»»
TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/154180043
In channels, zeroing of gp.waiting is missed on a closed channel panic.
m.morebuf.g is not zeroed.
I don't expect the latter causes any problems, but just in case.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/151610043
TestMakeFuncVariadic only called the variadic function via Call and
CallSlice, not via a direct function call.
I thought these tests would fail under gccgo tip, but they don't. Still seems worth having though.
LGTM=iant
R=golang-codereviews, gobot, iant
CC=golang-codereviews
https://golang.org/cl/152060043
This change prevents confusion in the garbage collector.
The collector wants to make sure that every pointer it finds
isn't junk. Its criteria for junk is (among others) points
to a "free" span.
Because the stack shrinker modifies pointers in the heap,
there is a race condition between the GC scanner and the
shrinker. The GC scanner can see old pointers (pointers to
freed stacks). In particular this happens with SudoG.elem
pointers.
Normally this is not a problem, as pointers into stack spans
are ok. But if the freed stack is the last one in its span,
the span is marked as "free" instead of "contains stacks".
This change makes sure that even if the GC scanner sees
an old pointer, the span into which it points is still
marked as "contains stacks", and thus the GC doesn't
complain about it.
This change will make the GC pause a tiny bit slower, as
the stack freeing now happens in serial with the mark pause.
We could delay the freeing until the mutators start back up,
but this is the simplest change for now.
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/158750043
These tests fail when using gccgo. In gccgo using Interface
on the value of a method function is implemented using a
variant of MakeFunc. That approach did not correctly handle
variadic functions.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/151280043
The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes#8625.
Fixes#8565.
On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time: -3.13%
cputime: -3.22%
gc-pause-one: -15.71%
gc-pause-total: -15.71%
GOMAXPROCS=32
time: -1.96%
cputime: -4.43%
gc-pause-one: -6.22%
gc-pause-total: -6.22%
LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043
Out of stack space due to new 2-word call in freedefer.
Go back to smaller function calls.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/152340043
It appears to be an opaque bit pattern more than a pointer.
The Go garbage collector has discovered that for m0
it is set to 0x4c.
Should fix Windows build.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/149640043
Another dangling stack pointer in a cached structure.
Same as SudoG.elem and SudoG.selectdone.
Definitely a fix, and the new test in freedefer makes the
crash reproducible, but probably not a complete fix.
I have seen one dangling pointer in a Defer.panic even
after this fix; I cannot see where it could be coming from.
I think this will fix the solaris build.
I do not think this will fix the occasional failure on the darwin build.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/155080043
This avoids a pop-up box on OS X and it avoids
a test failure if something is using 5555.
I apologize for not noticing this during the review.
TBR=r
CC=golang-codereviews
https://golang.org/cl/152320044
It seems reasonable that people might want to look up the
ImportComment with "go list".
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/143600043
I have a CL which at every gc looks through data and bss
sections for nonpointer data (according to gc maps) that
looks like a pointer. These are potential missing roots.
The only thing it finds are begnign, storing stack pointers
into m0.scalararg[1] and never cleaning them up. Let's
clean them up now so the test CL passes all.bash cleanly.
The test CL can't be checked in because we might store
pointer-looking things in nonpointer data by accident.
LGTM=iant
R=golang-codereviews, iant, khr
CC=golang-codereviews
https://golang.org/cl/153210043
We no longer have full type information in the heap, so
we can't dump that any more. Instead we dump ptr/noptr
maps so at least we can compute graph connectivity.
In addition, we still dump Iface/Eface types so together
with dwarf type info we might be able to reconstruct
types of most things in the heap.
LGTM=dvyukov
R=golang-codereviews, dvyukov, rsc, khr
CC=golang-codereviews
https://golang.org/cl/155940043
