In order to support different compression levels, make the
encoder type public, and add an Encoder method to it.
Fixes#8499.
LGTM=nigeltao
R=nigeltao, ruiu
CC=golang-codereviews
https://golang.org/cl/129190043
I changed all the NACL_SYSJMP to NACL_SYSCALL in
an earlier CL, but I missed the fact that NACL_SYSCALL
will push another return PC on the stack, so that the
arguments will no longer be in the right place.
Since we have to make our own call, we also have to
copy the arguments. Do that.
Fixes nacl/386 build.
TBR=minux
CC=golang-codereviews
https://golang.org/cl/135050044
This will allow structs containing Efaces in C to be
manipulated as structs containing real interfaces in Go.
The eface struct is still defined for use by Go code.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/133980044
Mutex is consistent with package sync, and when in the
unexported Go form it avoids having a conflcit between
the type (now mutex) and the function (lock).
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/133140043
This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.
This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
all use.
Fixes#8533.
LGTM=iant
R=golang-codereviews, aram, gobot, iant, minux
CC=golang-codereviews
https://golang.org/cl/132000043
NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.
The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.
The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.
If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.
Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.
This fixes the failure during the nacl/amd64p32 build.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/135050043
The NaCl "system calls" were assumed to have a compatible
return convention with the C compiler, and we were using
tail jumps to those functions. Don't do that anymore.
Correct mistake introduced in newstackcall duringconversion
from (SP) to (FP) notation. (Actually this fix, in asm_amd64p32.s,
slipped into the C compiler change, but update the name to
match what go vet wants.)
Correct computation of caller stack pointer in morestack:
on amd64p32, the saved PC is the size of a uintreg, not uintptr.
This may not matter, since it's been like this for a while,
but uintreg is the correct one. (And on non-NaCl they are the same.)
This will allow the NaCl build to get much farther.
It will probably still not work completely.
There's a bug in 6l that needs fixing too.
TBR=minux
CC=golang-codereviews
https://golang.org/cl/134990043
runtime._sfloat2 now returns the lr value on the stack, not R0.
Credit to Russ Cox for the fix.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133120045
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
nanotime1 is not a Go function and must not store its result at 0(FP).
That overwrites some data owned by the caller.
TBR=aram
CC=golang-codereviews
https://golang.org/cl/138730043
Windows needs the return result in AX, but runtime.sighandler
no longer stores it in AX. Load it back during the assembly trampoline.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/133980043
The Go calling convention uses more stack space than C.
On 64-bit systems we've been right up against the limit
(128 bytes, so only 16 words) and doing awful things to
our source code to work around it. Instead of continuing
to do awful things, raise the limit to 160 bytes.
I am prepared to raise the limit to 192 bytes if necessary,
but I think this will be enough.
Should fix current link-time stack overflow errors on
- nacl/arm
- netbsd/amd64
- openbsd/amd64
- solaris/amd64
- windows/amd64
TBR=r
CC=golang-codereviews, iant
https://golang.org/cl/131450043
To date, the C compilers and Go compilers differed only in how
values were returned from functions. This made it difficult to call
Go from C or C from Go if return values were involved. It also made
assembly called from Go and assembly called from C different.
This CL changes the C compiler to use the Go conventions, passing
results on the stack, after the arguments.
[Exception: this does not apply to C ... functions, because you can't
know where on the stack the arguments end.]
By doing this, the CL makes it possible to rewrite C functions into Go
one at a time, without worrying about which languages call that
function or which languages it calls.
This CL also updates all the assembly files in package runtime to use
the new conventions. Argument references of the form 40(SP) have
been rewritten to the form name+10(FP) instead, and there are now
Go func prototypes for every assembly function called from C or Go.
This means that 'go vet runtime' checks effectively every assembly
function, and go vet's output was used to automate the bulk of the
conversion.
Some functions, like seek and nsec on Plan 9, needed to be rewritten.
Many assembly routines called from C were reading arguments
incorrectly, using MOVL instead of MOVQ or vice versa, especially on
the less used systems like openbsd.
These were found by go vet and have been corrected too.
If we're lucky, this may reduce flakiness on those systems.
Tested on:
darwin/386
darwin/amd64
linux/arm
linux/386
linux/amd64
If this breaks another system, the bug is almost certainly in the
sys_$GOOS_$GOARCH.s file, since the rest of the CL is tested
by the combination of the above systems.
LGTM=dvyukov, iant
R=golang-codereviews, 0intro, dave, alex.brainman, dvyukov, iant
CC=golang-codereviews, josharian, r
https://golang.org/cl/135830043
Every change to g->atomicstatus is now done atomically so that we can
ensure that all gs pass through a gc safepoint on demand. This allows
the GC to move from one phase to the next safely. In some phases the
stack will be scanned. This CL only deals with the infrastructure that
allows g->atomicstatus to go from one state to another. Future CLs
will deal with scanning and monitoring what phase the GC is in.
The major change was to moving to using a Gscan bit to indicate that
the status is in a scan state. The only bug fix was in oldstack where
I wasn't moving to a Gcopystack state in order to block scanning until
the new stack was in place. The proc.go file is waiting for an atomic
load instruction.
LGTM=rsc
R=golang-codereviews, dvyukov, josharian, rsc
CC=golang-codereviews, khr
https://golang.org/cl/132960044
Update #8527
Fixes two warnings:
src/cmd/gc/mparith3.c:255:10: runtime error: shift exponent 52 is too large for 32-bit type 'int'
src/cmd/gc/mparith3.c:254:14: runtime error: shift exponent 52 is too large for 32-bit type 'int'
LGTM=rsc
R=r, dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/134940044
Also make genzabbrs.go more self-contained.
Also run it (on Linux; does that matter?) to update the table.
LGTM=rsc
R=rsc, alex.brainman
CC=golang-codereviews
https://golang.org/cl/128350044
I noticed that 5g doesn't flush the float64 result back to the stack, hence the change in the function signature. I'm wondering if I should also change the signature for the other two functions.
LGTM=rsc
R=minux, josharian, rsc
CC=golang-codereviews
https://golang.org/cl/132990044
There are both many callers and many implementations of these
interfaces, so make the contract explicit. Callers generally
assume this, and at least the standard library and other
implementations obey this, but it's never stated explicitly,
making it somewhat risky to assume.
LGTM=gri, rsc
R=golang-codereviews, gri
CC=golang-codereviews, r, rsc
https://golang.org/cl/132150043
Also: use 0x644 file permission if a new file
is created (should not happen anymore, though).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/126610044
Simplify the invocation (and speed it up substantially) in preparation
for move to go generate.
LGTM=bradfitz, mpvl
R=mpvl, bradfitz, josharian
CC=golang-codereviews
https://golang.org/cl/135790043
Once and for all.
Broken in cl/108640043.
I've messed it before. To test scavenger-related changes
one needs to alter the constants during final testing.
And then it's very easy to submit with the altered constants.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, rsc
https://golang.org/cl/136720044
Deleted in cl/123700044.
I am not sure whether I need to restore it,
or delete rest of the uses...
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/129580043
Before, a slice with cap=0 or a string with len=0 might have its
base pointer pointing beyond the actual slice/string data into
the next block. The collector had to ignore slices and strings with
cap=0 in order to avoid misinterpreting the base pointer.
Now, a slice with cap=0 or a string with len=0 still has a base
pointer pointing into the actual slice/string data, no matter what.
The collector can now always scan the pointer, which means
strings and slices are no longer special.
Fixes#8404.
LGTM=khr, josharian
R=josharian, khr, dvyukov
CC=golang-codereviews
https://golang.org/cl/112570044
Fixes test failure in build, probably a good idea anyway.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/131210043
It was respected by unmarshal, but not marshal, so they didn't
round-trip.
Fixes#8582
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/132960043
A whole thread is too much for background scavenger that sleeps all the time anyway.
We already have sysmon thread that can do this work.
Also remove g->isbackground and simplify enter/exitsyscall.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr, rlh
https://golang.org/cl/108640043
Normally, an expression of the form x.f or *y can be reordered
with function calls and communications.
Select is stricter than normal: each channel expression is evaluated
in source order. If you have case <-x.f and case <-foo(), then if the
evaluation of x.f causes a panic, foo must not have been called.
(This is in contrast to an expression like x.f + foo().)
Enforce this stricter ordering.
Fixes#8336.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews, r
https://golang.org/cl/126570043
Reduce duration of critical section,
make pcbuf local to function.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, rsc
https://golang.org/cl/102600043
Update #8525
Some temporary variables that were fully registerized nevertheless had stack space allocated for them because the Addrs were still marked as having associated nodes.
Distribution of stack space reserved for temporary variables while running make.bash (6g):
BEFORE
40.89% 7026 allocauto: 0 to 0
7.83% 1346 allocauto: 0 to 24
7.22% 1241 allocauto: 0 to 8
6.30% 1082 allocauto: 0 to 16
4.96% 853 allocauto: 0 to 56
4.59% 789 allocauto: 0 to 32
2.97% 510 allocauto: 0 to 40
2.32% 399 allocauto: 0 to 48
2.10% 360 allocauto: 0 to 64
1.91% 328 allocauto: 0 to 72
AFTER
48.49% 8332 allocauto: 0 to 0
9.52% 1635 allocauto: 0 to 16
5.28% 908 allocauto: 0 to 48
4.80% 824 allocauto: 0 to 32
4.73% 812 allocauto: 0 to 8
3.38% 581 allocauto: 0 to 24
2.35% 404 allocauto: 0 to 40
2.32% 399 allocauto: 0 to 64
1.65% 284 allocauto: 0 to 56
1.34% 230 allocauto: 0 to 72
LGTM=rsc
R=rsc
CC=dave, dvyukov, golang-codereviews, minux
https://golang.org/cl/126160043
cmd/6g has been doing this for a long time.
Arrays are still problematic on 5g because the addressing
for t[0] where local var t has type [3]uintptr takes the address of t.
That's issue 8125.
Fixes#8123.
LGTM=josharian
R=josharian, dave
CC=golang-codereviews
https://golang.org/cl/102890046
CL 130240043 did this but broke ARM, because
it made newErrorCString start allocating, so we rolled
it back in CL 133810043.
CL 133820043 removed that allocation.
Try again.
Fixes#8405.
LGTM=bradfitz, dave
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, r
https://golang.org/cl/133830043
Now 'go vet runtime' only shows:
malloc.go:200: possible misuse of unsafe.Pointer
malloc.go:214: possible misuse of unsafe.Pointer
malloc.go:250: possible misuse of unsafe.Pointer
stubs.go:167: possible misuse of unsafe.Pointer
Those are all unavoidable.
LGTM=josharian
R=golang-codereviews, dvyukov, josharian
CC=dave, golang-codereviews
https://golang.org/cl/135730043
It now serves as an example for go generate as well as for yacc.
NOTE: Depends on go generate, which is not yet checked in.
This is a proof of concept of the approach.
That is https://golang.org/cl/125580044.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/125620044
This is based on the crash dump provided by Alan
and on mental experiments:
sweep 0 74
fatal error: gc: unswept span
runtime stack:
runtime.throw(0x9df60d)
markroot(0xc208002000, 0x3)
runtime.parfordo(0xc208002000)
runtime.gchelper()
I think that when we moved all stacks into heap,
we introduced a bunch of bad data races. This was later
worsened by parallel stack shrinking.
Observation 1: exitsyscall can allocate a stack from heap at any time (including during STW).
Observation 2: parallel stack shrinking can (surprisingly) grow heap during marking.
Consider that we steadily grow stacks of a number of goroutines from 8K to 16K.
And during GC they all can be shrunk back to 8K. Shrinking will allocate lots of 8K
stacks, and we do not necessary have that many in heap at this moment. So shrinking
can grow heap as well.
Consequence: any access to mheap.allspans in GC (and otherwise) must take heap lock.
This is not true in several places.
Fix this by protecting accesses to mheap.allspans and introducing allspans cache for marking,
similar to what we use for sweeping.
LGTM=rsc
R=golang-codereviews, rsc
CC=adonovan, golang-codereviews, khr, rlh
https://golang.org/cl/126510043
The low-level implementation of divide on ARM assumes that
it can panic with an error created by newErrorCString without
allocating. If we make interface data words require pointer values,
the current definition would require an allocation when stored
in an interface. Changing the definition to use unsafe.Pointer
instead of uintptr avoids the allocation. This change is okay
because the field really is a pointer (to a C string in rodata).
Update #8405.
This should make CL 133830043 safe to try again.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, r
https://golang.org/cl/133820043
This change broke divmod.go on all arm platforms.
««« original CL description
cmd/gc: change interface representation: only pointers in data word
Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.
Fixes#8405.
LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
»»»
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133810043
This is a very dumb translation to keep the code as close to the original C as possible.
LGTM=rsc
R=khr, minux, rsc, josharian
CC=golang-codereviews
https://golang.org/cl/126490043
Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.
Fixes#8405.
LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
This makes newproc invisible to the GC. This is a pretty simple change since parts of newproc already depends on being run on the M stack.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews, khr
https://golang.org/cl/129520043
The current code is correct, but vet does not understand it:
asm_amd64.s:963: [amd64] invalid MOVL of ret+0(FP); int64 is 8-byte value
asm_amd64.s:964: [amd64] invalid offset ret+4(FP); expected ret+0(FP)
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/125200044
Fix issue by always appending newline after user input, before
the closing curly bracket. The adjust func is modified to remove
this new newline.
Add test case (it fails before CL, passes after).
Fixes#8411.
LGTM=gri
R=golang-codereviews, bradfitz, josharian, gri
CC=golang-codereviews
https://golang.org/cl/124700043
Fixes#8503.
Thanks to no.smile.face for the original report.
LGTM=bradfitz, r, ruiu
R=bradfitz, ruiu, r
CC=golang-codereviews
https://golang.org/cl/132730043
1) Interpret a comment of the form
//gofmt <flags>
in test files to drive the respective
gofmt command. Eliminates the need to
enumerate all test files in the test
harness.
2) Added -update flag to make it easier
to update test cases.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/130440043
Update #8527
Fixes, src/cmd/6l/../ld/pcln.c:93:18: runtime error: left shift of negative value -2
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/127440043
This files were added accidentally and are
not required for running the tests (they
are produced by failing tests for easier
debugging).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/131030044
Fixes compilation of runtime on Solaris where the inner struct
was not called "_4_".
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/129460043
Australian timezones abbreviation for standard and daylight saving time were recently
changed from EST for both to AEST and AEDT in the icann tz database (see changelog
on www.iana.org/time-zones).
A test in the time package was written to check that the ParseInLocation function
understand that Feb EST and Aug EST are different time zones, even though they are
both called EST. This is no longer the case, and the Date function now returns
AEST or AEDT for australian tz on every Linux system with an up to date tz database
(and this makes the test fail).
Since I wasn't able to find another country that 1) uses daylight saving and 2) has
the same abbreviation for both on tzdata, I changed the test to make sure that
ParseInLocation does not get confused when it parses, in different locations, two
dates with the same abbreviation (this was suggested in the mailing list).
Fixes#8547.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/130920043
Cleanup before converting to Go.
Fortunately nobody using it, because it is incorrect:
monotonic runtime time instead of claimed real time.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/129480043
These are required for chans, semaphores, timers, etc.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/123640043
UndefinedBehaviorSanitizer claims it is UB in C:
src/cmd/gc/racewalk.c:422:37: runtime error: member access within null pointer of type 'Node' (aka 'struct Node')
src/cmd/gc/racewalk.c:423:37: runtime error: member access within null pointer of type 'Node' (aka 'struct Node')
LGTM=rsc
R=dave, rsc
CC=golang-codereviews
https://golang.org/cl/125570043
Init GC later as it needs to read GOGC env var.
Fixes#8562.
LGTM=daniel.morsing, rsc
R=golang-codereviews, daniel.morsing, rsc
CC=golang-codereviews, khr, rlh
https://golang.org/cl/130990043
Calling ReadMemStats which does stoptheworld on m0 holding locks
was not a good idea.
Stoptheworld holding locks is a recipe for deadlocks (added check for this).
Stoptheworld on g0 may or may not work (added check for this as well).
As far as I understand scavenger will print incorrect numbers now,
as stack usage is not subtracted from heap. But it's better than deadlocking.
LGTM=khr
R=golang-codereviews, rsc, khr
CC=golang-codereviews, rlh
https://golang.org/cl/124670043
zsyscall_windows_386.go and zsyscall_windows_amd64.go contain same bytes
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/124640043
The existing lock needed to be held longer. If a timeout occured
while writing (but after the guarded timeout check), the writes
would clobber a future connection's buffer.
Also remove a harmless warning by making Write also set the
flag that headers were sent (implicitly), so we don't try to
write headers later (a no-op + warning) on timeout after we've
started writing.
Fixes#8414Fixes#8209
LGTM=ruiu, adg
R=adg, ruiu
CC=golang-codereviews
https://golang.org/cl/123610043
Half the code in the garbage collector accesses the bitmap
as an array of bytes instead of as an array of uintptrs.
This is tricky to do correctly in a portable fashion,
it breaks on big-endian systems.
Make the bitmap a byte array.
Simplifies markallocated, scanblock and span sweep along the way,
as we don't need to recalculate bitmap position for each word.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/125250043
We allocate scannable memory w/o type only in few places in runtime.
All these cases are not-performance critical (e.g. G or finq args buffer),
and in long term they all need to go away.
It's not worth it to have special code for this case in mallocgc.
So use special fake "notype" type for such allocations.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/127450044
Currently goroutines in onM can't be copied/shrunk
(including the very goroutine that triggers GC).
Special case onM to allow copying.
LGTM=daniel.morsing, khr
R=golang-codereviews, daniel.morsing, khr, rsc
CC=golang-codereviews, rlh
https://golang.org/cl/124550043
Newly allocated memory is subtracted from inuse, while it was never added to inuse.
Span leftovers are subtracted from both inuse and idle,
while they were never added.
Fixes#8544.
Fixes#8430.
LGTM=khr, cookieo9
R=golang-codereviews, khr, cookieo9
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/130200044
We need to change the interface value representation for
concurrent garbage collection, so that there is no ambiguity
about whether the data word holds a pointer or scalar.
This CL does NOT make any representation changes.
Instead, it removes representation assumptions from
various pieces of code throughout the tree.
The isdirectiface function in cmd/gc/subr.c is now
the only place that decides that policy.
The policy propagates out from there in the reflect
metadata, as a new flag in the internal kind value.
A follow-up CL will change the representation by
changing the isdirectiface function. If that CL causes
problems, it will be easy to roll back.
Update #8405.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/129090043
The change to pc-relative addressing will make this illegal.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/129890043
Update #8527
Fixes, cmd/6g/reg.c:847:24: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
LGTM=minux, rsc
R=minux, rsc
CC=dvyukov, golang-codereviews
https://golang.org/cl/129290043
type T byte
func (T) String() string { return "X" }
fmt.Sprintf("%s", []T{97, 98, 99, 100}) == "abcd"
fmt.Sprintf("%x", []T{97, 98, 99, 100}) == "61626364"
fmt.Sprintf("%v", []T{97, 98, 99, 100}) == "[X X X X]"
This change makes the last case print correctly.
Before, it would have been "[97 98 99 100]".
Fixes#8360.
LGTM=r
R=r, dan.kortschak
CC=golang-codereviews
https://golang.org/cl/129330043
Improve performance of move-to-front by using cache-friendly
copies instead of doubly-linked list. Simplify so that the
underlying slice is the object. Remove the n=0 special case,
which was actually slower with the copy approach.
benchmark old ns/op new ns/op delta
BenchmarkDecodeDigits 26429714 23859699 -9.72%
BenchmarkDecodeTwain 76684510 67591946 -11.86%
benchmark old MB/s new MB/s speedup
BenchmarkDecodeDigits 1.63 1.81 1.11x
BenchmarkDecodeTwain 1.63 1.85 1.13x
Updates #6754.
LGTM=adg, agl, josharian
R=adg, agl, josharian
CC=golang-codereviews
https://golang.org/cl/131840043
Currently we do the following dance after sweeping a span:
1. lock mcentral
2. remove the span from a list
3. unlock mcentral
4. unmark span
5. lock mheap
6. insert the span into heap
7. unlock mheap
8. lock mcentral
9. observe empty list
10. unlock mcentral
11. lock mheap
12. grab the span
13. unlock mheap
14. mark span
15. lock mcentral
16. insert the span into empty list
17. unlock mcentral
This change short-circuits this sequence to nothing,
that is, we just cache and use the span after sweeping.
This gives us functionality similar (even better) to tcmalloc's transfer cache.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 22.2 19.5 -12.16%
BenchmarkMalloc16 31.0 26.6 -14.19%
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/119550043
Mallocgc must be atomic wrt GC, but for performance reasons
don't acquirem/releasem on fast path. The code does not have
split stack checks, so it can't be preempted by GC.
Functions like roundup/add are inlined. And onM/racemalloc are nosplit.
Also add debug code that checks these assumptions.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 20.5 17.2 -16.10%
BenchmarkMalloc16 29.5 27.0 -8.47%
BenchmarkMallocTypeInfo8 31.5 27.6 -12.38%
BenchmarkMallocTypeInfo16 34.7 30.9 -10.95%
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/123100043
Fixes#8480.
This CL reapplies CL 114420043. This attempt doesn't blow up when encountering hidden symbols.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/128310043
When building golang, the environment variable GOROOT_FINAL can be set
to indicate a different installation location from the build
location. This works fine, except that the goc2c build step embeds
line numbers in the resulting c source files that refer to the build
location, no the install location.
This would not be a big deal, except that in turn the linker uses the
location of runtime/string.goc to embed the gdb script in the
resulting binary and as a net result, the debugger now complains that
the script is outside its load path (it has the install location
configured).
See https://code.google.com/p/go/issues/detail?id=8524 for the full
description.
Fixes#8524.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/128230046
bv.data is an array of uint32s but the code was using
offsets computed for an array of bytes.
Add a test for stack GC info.
Fixes#8531.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/124450043
E.g., here's the new "go build" output:
$ go build misc/cgo/errors/issue8442.go
# command-line-arguments
could not determine kind of name for C.issue8442foo
gcc errors for preamble:
misc/cgo/errors/issue8442.go:11:19: error: unknown type name 'UNDEF'
Fixes#8442.
LGTM=iant
R=iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/129160043
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes#8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
Restore https://golang.org/cl/41040043 after GC rewrite.
Original description:
On the plus side, we don't need to change the bits on malloc and free.
On the downside, we need to mark objects in the free lists during GC.
But the free lists are small at GC time, so it should be a net win.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 21.9 20.4 -6.85%
BenchmarkMalloc16 31.1 29.6 -4.82%
LGTM=khr
R=khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/122280043
Basically this cleanup replaces all the usage usages of strcmp() == 0,
found by the following command line:
$ grep -R strcmp cmd/dist | grep "0"
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/123330043
The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
This allows implementing address-of-global
as a pc-relative address instead of as a
32-bit integer constant.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/128070045
This allows changing the addressing mode for constant
global addresses to use pc-relative addressing.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/129830043
Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.
LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043
codeblk and datblk were truncating their
arguments to int32. Don't do that.
LGTM=dvyukov, rminnich
R=iant, dvyukov, rminnich
CC=golang-codereviews
https://golang.org/cl/126050043
See golang.org/s/go14customimport for design.
Added case to deps_test to allow go/build to import regexp.
Not a new dependency, because go/build already imports go/doc
which imports regexp.
Fixes#7453.
LGTM=r
R=r, josharian
CC=golang-codereviews
https://golang.org/cl/124940043
It's unclear why we do this broken double-checked locking.
The mutex is not held for the whole duration of CPU profiling.
Fixes#8365.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/116290043
This function does not have a declaration/prototype in a.h, and it is used only
in buf.c, so it is local to it and thus can be marked as private by adding
'static' to it.
LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/122300043
misc/cgo/testgodefs was added by revision d1cf884a594f, but not
add to run.bash.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/129760044
This makes GCC behavior (and cgo build failures) deterministic.
Fixes#8487.
Ran this shell command on linux/amd64 (Ubuntu 12.04) before and
after this change:
for x in `seq 100`; do
go tool cgo -debug-gcc=true issue8441.go 2>&1 | md5sum
done | sort | uniq -c
Before:
67 2cdcb8c7c4e290f7d9009abc581b83dd -
10 9a55390df94f7cec6d810f3e20590789 -
10 acfad22140d43d9b9517bbc5dfc3c0df -
13 c337f8fee2304b3a8e3158a4362d8698 -
After:
100 785c316cbcbcd50896695050e2fa23c1 -
LGTM=minux, iant
R=golang-codereviews, bradfitz, minux, iant
CC=golang-codereviews
https://golang.org/cl/126990043
Credit to Rémy for finding and writing test case.
Fixes#8325.
LGTM=r
R=golang-codereviews, r
CC=dave, golang-codereviews, iant, remyoudompheng
https://golang.org/cl/124950043
The >>1 shift needs to happen before converting to int32, otherwise
large values will decode with an incorrect sign bit.
The <<31 shift can happen before or after, but before is consistent
with liblink and the go12symtab doc.
Bug demo at http://play.golang.org/p/jLrhPUakIu
LGTM=rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/119630043
When formatting time zone offsets with seconds using the stdISO8601Colon
and stdNumColon layouts, the colon was missing between the hour and minute
parts.
Fixes#8497.
LGTM=r
R=golang-codereviews, iant, gobot, r
CC=golang-codereviews
https://golang.org/cl/126840043
On OS X 10.10 Yosemite, if you have a directory that can be returned
in a single getdirentries64 call (for example, a directory with one file),
and you read from the directory at EOF twice, you get EOF both times:
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
getdirentries64(fd) returns 0 (EOF)
But if you remove the file in the middle between the two calls, the
second call returns an error instead.
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
remove("dir/file")
getdirentries64(fd) returns ENOENT/EINVAL
Whether you get ENOENT or EINVAL depends on exactly what was
in the directory. It is deterministic, just data-dependent.
This only happens in small directories. A directory containing more data
than fits in a 4k getdirentries64 call will return EOF correctly.
(It's not clear if the criteria is that the directory be split across multiple
getdirentries64 calls or that it be split across multiple file system blocks.)
We could change package os to avoid the second read at EOF,
and maybe we should, but that's a bit involved.
For now, treat the EINVAL/ENOENT as EOF.
With this CL, all.bash passes on my MacBook Air running
OS X 10.10 (14A299l) and Xcode 6 beta 5 (6A279r).
I tried filing an issue with Apple using "Feedback Assistant", but it was
unable to send the report and lost it.
C program reproducing the issue, also at http://swtch.com/~rsc/readdirbug.c:
#include <stdio.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
static void test(int);
int
main(void)
{
int fd, n;
DIR *dir;
struct dirent *dp;
struct stat st;
char buf[10000];
long basep;
int saw;
if(stat("/tmp/readdirbug", &st) >= 0) {
fprintf(stderr, "please rm -r /tmp/readdirbug and run again\n");
exit(1);
}
fprintf(stderr, "mkdir /tmp/readdirbug\n");
if(mkdir("/tmp/readdirbug", 0777) < 0) {
perror("mkdir /tmp/readdirbug");
exit(1);
}
fprintf(stderr, "create /tmp/readdirbug/file1\n");
if((fd = creat("/tmp/readdirbug/file1", 0666)) < 0) {
perror("create /tmp/readdirbug/file1");
exit(1);
}
close(fd);
test(0);
test(1);
fprintf(stderr, "ok - everything worked\n");
}
static void
test(int doremove)
{
DIR *dir;
struct dirent *dp;
int numeof;
fprintf(stderr, "\n");
fprintf(stderr, "opendir /tmp/readdirbug\n");
dir = opendir("/tmp/readdirbug");
if(dir == 0) {
perror("open /tmp/readdirbug");
exit(1);
}
numeof = 0;
for(;;) {
errno = 0;
dp = readdir(dir);
if(dp != 0) {
fprintf(stderr, "readdir: found %s\n", dp->d_name);
continue;
}
if(errno != 0) {
perror("readdir");
exit(1);
}
fprintf(stderr, "readdir: EOF\n");
if(++numeof == 3)
break;
if(doremove) {
fprintf(stderr, "rm /tmp/readdirbug/file1\n");
if(remove("/tmp/readdirbug/file1") < 0) {
perror("remove");
exit(1);
}
}
}
fprintf(stderr, "closedir\n");
closedir(dir);
}
Fixes#8423.
LGTM=bradfitz, r
R=golang-codereviews, bradfitz, dsymonds, dave, r
CC=golang-codereviews, iant
https://golang.org/cl/119530044
Current version of Getwd calls Stat that
calls Getwd therefore infinite recursion.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/119600043
The ast and printer don't care, and go/types can provide
a better error message.
This change requires an update to the tests for go/types
(go.tools repo). CL forthcoming.
Fixes#8493.
LGTM=adonovan
R=rsc, adonovan
CC=golang-codereviews
https://golang.org/cl/123010044
Some systems, like Ubuntu, pass --build-id when linking. The
effect is to put a note in the output file. This is not
useful when generating an object file with the -r option, as
it eventually causes multiple build ID notes in the final
executable, all but one of which are for tiny portions of the
file and are therefore useless.
Disable that by passing an explicit --build-id=none when
linking with -r on systems that might do this.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/119460043
There are lots of internal synchronization in gob,
so it makes sense to have parallel benchmarks.
Also add a benchmark with slices and interfaces.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/115960043
This lets us have non-main packages like cmd/internal or cmd/nm/internal/whatever.
The src/pkg migration (see golang.org/s/go14mainrepo) will allow this
as a natural side effect. The explicit change here just allows use of the
effect a little sooner.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/117630043
To do in another CL: make cmd/objdump use cmd/internal/objfile too.
There is a package placement decision in this CL:
cmd/internal/objfile instead of internal/objfile.
I chose to put internal under cmd to make clear (and enforce)
that no standard library packages should use this
(it's a bit dependency-heavy).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/123910043
Eliminating use of this extension makes it easier to port the Go runtime
to other compilers. This CL also disables the extension in cc to prevent
accidental use.
LGTM=rsc, khr
R=rsc, aram, khr, dvyukov
CC=axwalk, golang-codereviews
https://golang.org/cl/106790044
This makes os.Getwd mimic C getwd on OS X,
and possibly other systems. The change on OS X
was a regression from 1.2 to 1.3.
Fixes#8400.
LGTM=bradfitz
R=iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/118970043
FlagNoGC is unused now.
FlagNoInvokeGC is unneeded as we don't invoke GC
on g0 and when holding locks anyway.
mal/malloc have very few uses and you never remember
the exact set of flags they use and the difference between them.
Moreover, eventually we need to give exact types to all allocations,
something what mal/malloc do not support.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/117580043
Shrinkstack does not touch normal heap anymore,
so we can shink stacks concurrently with marking.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, khr, rlh, rsc
https://golang.org/cl/122130043
Among other things, this allows users to match the decoded
pieces with the original XML, which can be necessary for
implementing standards like XML signatures.
Fixes#8484.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/122960043
This fixes two problems: x/internal/y/z was using parent = x/internal/y instead of x,
and hasPathPrefix only looks at /, not \ for Windows.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/121280045
Introduce the mFunction type to represent an mcall/onM-able function.
Name such functions using _m.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/121320043
Hashing on the bytes instead of the words does
a (much) better job of using all the bits, so that
maps of floats have linear performance.
LGTM=khr
R=golang-codereviews, khr
CC=adonovan, golang-codereviews
https://golang.org/cl/126720044
The implementation 'return 0' results in too many collisions.
LGTM=khr
R=golang-codereviews, adonovan, khr
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/125720044
1) The arrayindexof lookup function is O(n). Replace with O(1) lookups.
2) The checkptxt function is O(n²) and is purely for debugging.
Only run when the debugging flags are turned on.
3) Iterating over sparse bitmaps can be done faster word by word.
Introduce and use bvnext for that.
Run times before and after, on my 2.5 GHz Core i5 MacBook Pro.
x.go 9.48 0.84 issue 8259
x100.go 0.01 0.01 issue 8354
x1000.go 0.10 0.10
x2000.go 0.62 0.19
x3000.go 1.33 0.34
x4000.go 2.29 0.49
x5000.go 3.89 0.67
x6000.go 5.00 0.90
x7000.go 6.70 1.13
x8000.go 9.44 1.38
x9000.go 11.23 1.87
x10000.go 13.78 2.09
Fixes#8259.
Fixes#8354.
LGTM=iant, r
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/125720043
The linker currently produces the DWARF 3 DW_TAG_unspecified_type tag, however the Reader in debug/dwarf will panic whenever that tag is encountered.
Fixes#8437.
LGTM=rsc
R=golang-codereviews, bradfitz, iant, rsc
CC=golang-codereviews
https://golang.org/cl/117280043
It can happen legitimately if a profiling signal arrives at just the wrong moment.
It's harmless.
Fixes#8153.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews, iant, r
https://golang.org/cl/118670043
Full spans can't be passed to UncacheSpan since we get rid of free.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/119490044
Since CL 115060044, mkanames declares an empty
array in anames8.c and anames6.c, which is not
valid for the Plan 9 compiler.
char* cnames8[] = {
};
This change makes mkanames not declaring the
cnames array when no C_ constants are found.
LGTM=iant
R=minux, iant
CC=golang-codereviews
https://golang.org/cl/117680043
The helps certain diagnostics and also removed duplicated enums as a side effect.
LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/115060044
Encode MOV $0, %ax as XOR %eax, %eax instead of
XOR %rax, %rax. If an operand register does not
need REX.w bit (i.e. not one of R8-R15), it is
encoded in 2 bytes instead of 3 bytes.
LGTM=rsc
R=golang-codereviews, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/115580044
Instead of immediately completing pointer type mappings, add them to
a queue to allow them to be completed later. This fixes issues caused
by Type() returning arbitrary in-progress type mappings.
Fixes#8368.
Fixes#8441.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/122850043
Instead of including <sys/types.h> to get size_t, instead include
the ISO C standard <stddef.h> header, which defines fewer additional
types at risk of colliding with the user code. In particular, this
prevents collisions between <sys/types.h>'s userspace definitions with
the kernel definitions needed by defs_linux.go.
Also, -cdefs mode uses #pragma pack, so we can keep misaligned fields.
Fixes#8477.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/120610043
Before fixing issue 6579 this CL separates DNS transport from
DNS message interaction to make it easier to add builtin DNS
resolver control logic.
Update #6579
LGTM=alex, kevlar
R=golang-codereviews, alex, gobot, iant, minux, kevlar
CC=golang-codereviews
https://golang.org/cl/101220044
Update #6677
When a struct contains an anonymous union, use the type and
name of the first field in the union.
This should make the glibc <sys/resource.h> file work; in that
file struct rusage has fields like
__extension__ union
{
long int ru_maxrss;
__syscall_slong_t __ru_maxrss_word;
};
in which the field that matters is ru_maxrss and
__ru_maxrss_word just exists to advance to the next field on
systems where the kernel uses long long fields but userspace
expects long fields.
LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/106260044
We call scanblock for lots of small root pieces
e.g. for every stack frame args and locals area.
Every scanblock invocation calls getempty/putempty,
which accesses lock-free stack shared among all worker threads.
One-element local cache allows most scanblock calls
to proceed without accessing the shared stack.
LGTM=rsc
R=golang-codereviews, rlh
CC=golang-codereviews, khr, rsc
https://golang.org/cl/121250043
If the process exits before the spawned goroutine
completes, it'll miss the data race.
LGTM=bradfitz
R=bradfitz
CC=dvyukov, golang-codereviews
https://golang.org/cl/122120043
Camlistore uses this pattern to do streaming writes, as do
others I imagine, and it was broken by the lazy boundary
change.
LGTM=dvyukov, ruiu
R=ruiu, dvyukov
CC=golang-codereviews, mathieu.lonjaret
https://golang.org/cl/116690043
Breaks Camlistore by introducing a datarace. See comments on
https://golang.org/cl/95760043/ for details.
I'll add a new test to lock-in the current behavior in a
subsequent CL.
I don't think Camlistore is particularly unique here: it's doing
the obvious thing to stream a multipart body to a server
using a goroutine feeding the multipart writer.
««« original CL description
mime/multipart: delay reading random source
If a user sets his/her own boundary string with SetBoundary,
we don't need to call randomBoundary at all.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/95760043
»»»
LGTM=ruiu
R=ruiu
CC=golang-codereviews, mathieu.lonjaret
https://golang.org/cl/117600043
We have an autogenerated version in zruntime_defs.
I am not sure what are the consequences as gdb never printed any values for me.
But it looks unnecessary to manually duplicate it.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, iant, khr
https://golang.org/cl/115660043
For consistency with other code, as that was the only use of
memcopy outside of alg.goc.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/122030044
The gccgo version of USED only accepts a single variable, so
this simplifies merging.
LGTM=minux, dave
R=golang-codereviews, minux, dave
CC=golang-codereviews
https://golang.org/cl/115630043
Popular tools both add incorrect trailing zeroes to the zip
extras, and popular tools accept trailing zeros. We seemed to
be the only ones being strict here. Stop being strict. :(
Fixes#8186
LGTM=ruiu, adg, dave
R=adg, ruiu, dave
CC=frohrweck, golang-codereviews
https://golang.org/cl/117550044
This CL removes sockaddrToAddr functions from socket creation
operations to avoid the bug like issue 7183.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/105100046
Avoid some pressure on the global mutex by lifting the call to userType
out of the closure.
TOTH to Matt Harden.
LGTM=crawshaw, ruiu
R=golang-codereviews, crawshaw, ruiu
CC=golang-codereviews
https://golang.org/cl/117520043
A good cleanup anyway, and it makes some room for an additional
field needed for issue 8412.
Update #8412
LGTM=iant
R=iant, khr
CC=golang-codereviews
https://golang.org/cl/112700043
6a and 8a rearrange memmove such that the fallthrough from move_1or2 to move_0 ends up being a JMP to a RET. Insert an explicit RET to prevent such silliness.
Do the same for memclr as prophylaxis.
benchmark old ns/op new ns/op delta
BenchmarkMemmove1 4.59 4.13 -10.02%
BenchmarkMemmove2 4.58 4.13 -9.83%
LGTM=khr
R=golang-codereviews, dvyukov, minux, ruiu, bradfitz, khr
CC=golang-codereviews
https://golang.org/cl/120930043
Create proper closures so hash functions can be called
directly from Go. Rearrange calling convention so return
value is directly accessible.
LGTM=dvyukov
R=golang-codereviews, dvyukov, dave, khr
CC=golang-codereviews
https://golang.org/cl/119360043
Several reasons:
1. Significantly simplifies runtime.
2. This code proved to be buggy.
3. Free is incompatible with bump-the-pointer allocation.
4. We want to write runtime in Go, Go does not have free.
5. Too much code to free env strings on startup.
LGTM=khr
R=golang-codereviews, josharian, tracey.brendan, khr
CC=bradfitz, golang-codereviews, r, rlh, rsc
https://golang.org/cl/116390043
Stand-alone this test is fine. Run together with
others, however, the stack used can actually go
negative because other tests are freeing stack
during its execution.
This behavior is new with the new stack allocator.
The old allocator never returned (min-sized) stacks.
This test is fairly poor - it needs to run in
isolation to be accurate. Maybe we should delete it.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/119330044
The DISPATCH and CALLFN macro definitions depend on an inconsistency
between the internal cpp mini-implementation and the language proper in
whether center-dot is an identifier character. The macro depends on it not
being an identifier character, but the resulting code depends on it being one.
Remove the dependence on the inconsistency by placing the center-dot into
the macro invocation rather that the body.
No semantic change. This is just renaming macro arguments.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/119320043
This change introduces gomallocgc, a Go clone of mallocgc.
Only a few uses have been moved over, so there are still
lots of uses from C. Many of these C uses will be moved
over to Go (e.g. in slice.goc), but probably not all.
What should remain of C's mallocgc is an open question.
LGTM=rsc, dvyukov
R=rsc, khr, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/108840046
If a user sets his/her own boundary string with SetBoundary,
we don't need to call randomBoundary at all.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/95760043
preparing for the syscall package freeze.
««« original CL description
syscall: consolidate, simplify socket options for Unix-like systems
Also exposes common socket option functions on Solaris.
Update #7174
Update #7175
LGTM=aram
R=golang-codereviews, aram
CC=golang-codereviews
https://golang.org/cl/107280044
»»»
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/121880043
preparing for the syscall package freeze.
««« original CL description
syscall: regenerate z-files for darwin
Updates z-files from 10.7 kernel-based to 10.9 kernel-based.
LGTM=iant
R=golang-codereviews, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/102610045
»»»
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/114530044
This is meant to share my progress on Issue 8275, if it's useful to you. I'm not familiar with the formatter's internals, so this change is likely naive.
Change these calls to measure width in runes not bytes:
fmt.Printf("(%5q)\n", '§')
fmt.Printf("(%3c)\n", '§')
Fixes#8275.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/104320043
On Linux, adding a socket descriptor to epoll instance before getting
the EINPROGRESS return value from connect system call could be a root
cause of spurious on-connect events.
See golang.org/issue/8276, golang.org/issue/8426 for further information.
All credit to Jason Eggleston <jason@eggnet.com>
Fixes#8276.
Fixes#8426.
LGTM=dvyukov
R=dvyukov, golang-codereviews, adg, dave, iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/120820043
Implement the design described in:
https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub
Summary of the changes:
GC uses "2-bits per word" pointer type info embed directly into bitmap.
Scanning of stacks/data/heap is unified.
The old spans types go away.
Compiler generates "sparse" 4-bits type info for GC (directly for GC bitmap).
Linker generates "dense" 2-bits type info for data/bss (the same as stacks use).
Summary of results:
-1680 lines of code total (-1000+ in mgc0.c only)
-25% memory consumption
-3-7% binary size
-15% GC pause reduction
-7% run time reduction
LGTM=khr
R=golang-codereviews, rsc, christoph, khr
CC=golang-codereviews, rlh
https://golang.org/cl/106260045
Because the reference time is the reference time but beginners seem
to think otherwise, make it clearer you can't choose the reference time.
LGTM=josharian, dave
R=golang-codereviews, josharian, dave
CC=golang-codereviews
https://golang.org/cl/117250044
This change causes a TLS client and server to verify that received
elliptic curve points are on the expected curve. This isn't actually
necessary in the Go TLS stack, but Watson Ladd has convinced me that
it's worthwhile because it's pretty cheap and it removes the
possibility that some change in the future (e.g. tls-unique) will
depend on it without the author checking that precondition.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/115290046
ASN.1 elements can be optional, and can have a default value.
Traditionally, Go has omitted elements that are optional and that have
the zero value. I believe that's a bug (see [1]).
This change causes an optional element with a default value to only be
omitted when it has that default value. The previous behaviour of
omitting optional, zero elements with no default is retained because
it's used quite a lot and will break things if changed.
[1] https://groups.google.com/d/msg/Golang-nuts/9Ss6o9CW-Yo/KL_V7hFlyOAJFixes#7780.
R=bradfitz
LGTM=bradfitz
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews, r
https://golang.org/cl/86960045
