The implementation and use patterns of onM assume
that they run on either the m->curg or m->g0 stack.
Calling onM from m->gsignal has two problems:
(1) When not on g0, onM switches to g0 and then "back" to curg.
If we didn't start at curg, bad things happen.
(2) The use of scalararg/ptrarg to pass C arguments and results
assumes that there is only one onM call at a time.
If a gsignal starts running, it may have interrupted the
setup/teardown of the args for an onM on the curg or g0 stack.
Using scalararg/ptrarg itself would smash those.
We can fix (1) by remembering what g was running before the switch.
We can fix (2) by requiring that uses of onM that might happen
on a signal handling stack must save the old scalararg/ptrarg
and restore them after the call, instead of zeroing them.
The only sane way to do this is to introduce a separate
onM_signalsafe that omits the signal check, and then if you
see a call to onM_signalsafe you know the surrounding code
must preserve the old scalararg/ptrarg values.
(The implementation would be that onM_signalsafe just calls
fn if on the signal stack or else jumps to onM. It's not necessary
to have two whole copies of the function.)
(2) is not a problem if the caller and callee are both Go and
a closure is used instead of the scalararg/ptrarg slots.
For now, I think we can avoid calling onM from code executing
on gsignal stacks, so just reject it.
In the long term, (2) goes away (as do the scalararg/ptrarg slots)
once everything is in Go, and at that point fixing (1) would be
trivial and maybe worth doing just for regularity.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/135400043
Instead of making asmcgocall call asmcgocall_errno,
make both load args into registers and call a shared
assembly function.
On amd64, this costs 1 word in the asmcgocall_errno path
but saves 3 words in the asmcgocall path, and the latter
is what happens on critical nosplit paths on Windows.
On arm, this fixes build failures: asmcgocall was writing
the arguments for asmcgocall_errno into the wrong
place on the stack. Passing them in registers avoids the
decision entirely.
On 386, this isn't really needed, since the nosplit paths
have twice as many words to work with, but do it for consistency.
Update #8635
Fixes arm build (except GOARM=5).
TBR=iant
CC=golang-codereviews
https://golang.org/cl/134390043
I really hoped we could avoid this nonsense, but it appears not.
Should fix windows/amd64 build breakage.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/137120043
It is fundamentally unsafe to grow the stack once someone
has made a call to syscall.Syscall. That function takes 6 uintptr
arguments, but depending on the call some are pointers.
In fact, some might be pointers to stack values, and we don't know which.
That makes it impossible to copy the stack somewhere else.
Since we want to delete all the stack splitting code, relying only
on stack copying, make sure that Syscall never needs to split the stack.
The only thing Syscall does is:
call entersyscall
make the system call
call exitsyscall
As long as we make sure that entersyscall and exitsyscall
can live in the nosplit region, they won't ask for more stack.
Do this by making entersyscall and exitsyscall set up the
stack guard so that any call to a function with a split check
will cause a crash. Then move non-essential slow-path
work onto the m stack using onM and mark the rest of the
work nosplit. The linker will verify that the chain of nosplits
fits in the total nosplit budget.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/140950043
Because symtab.c was partially converted before,
the diffs are not terribly useful.
The earlier conversion was trying to refactor or
clean up the code in addition to doing the translation.
It also made a mistake by redefining Func to be something
users could overwrite.
I undid those changes, making symtab.go a more
literal line-for-line translation of symtab.c instead.
LGTM=josharian
R=golang-codereviews, dave, bradfitz, josharian
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/140880043
We often saw GC pauses of 0 ns, not just on Windows.
Google Compute Engine timer granularity might suck
too.
LGTM=rsc
R=rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/140910043
The race was in the old C code.
The new Go code does not have the race
and does not need the check.
LGTM=bradfitz, dvyukov
R=golang-codereviews, bradfitz, dvyukov
CC=golang-codereviews, rlh
https://golang.org/cl/140180043
Ignore memory access on g0/gsignal.
See the issue for context and explanation.
Fixes#8627.
LGTM=khr
R=golang-codereviews, mdempsky, khr
CC=golang-codereviews, rsc
https://golang.org/cl/137070043
Code to bring goroutines to a gc safepoint one at a time,
do some work such as scanning, and restart the
goroutine, and then move on to the next goroutine.
Currently this code does not do much useful work
but this infrastructure will be critical to future
concurrent GC work.
Fixed comments reviewers.
LGTM=rsc
R=golang-codereviews, rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/131580043
This gives them correct types in Go and also makes it
possible to use them to run Go code on an m stack.
LGTM=iant
R=golang-codereviews, dave, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/137970044
They were in proc.c mainly because there was no portable
traceback source file. As part of converting them to Go,
move to traceback.go.
In order to get access to the PC of _rt0_go,
rename to runtime.rt0_go.
LGTM=r
R=golang-codereviews, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/139110043
If system is busy burning cpu, it takes long time (about 300ms on
windows builders) to adjust prof thread priority. Once adjusted, prof
thread runs ahead of everyone else, but due to initial slowness, it
does not capture prof snapshots until start-up period is completed.
Change prof thread priority sooner, so it can start captures straight
away.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/134360043
While we are here, give the gc helper a real function name
that will appear in stack traces.
LGTM=rlh
R=rlh
CC=dvyukov, golang-codereviews
https://golang.org/cl/133470043
C and Go calling conventions are now compatible, so we
don't need two versions of this function.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/139080043
The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.
Tested on arm, amd64, amd64p32, and 386.
LGTM=r
R=golang-codereviews, remyoudompheng, dave, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/134200044
It looks like this has just always been broken:
the race detector handles running Go code on g0 of the main thread
and on g0 of any extra threads created by non-Go code, but it does
not handle running Go code on g0 of non-main threads created by Go.
Handle that.
Should fix the race build failures on the dashboard.
We're running into this now because we are running more
and more Go code on g0.
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/137910043
The exported Go definitions appearing in mprof.go are
copied verbatim from debug.go.
The unexported Go funcs and types are new.
The C Bucket type used a union and was not a line-for-line translation.
LGTM=remyoudompheng
R=golang-codereviews, remyoudompheng
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/137040043
Adding the #include to defs.c makes it get processed
by cmd/dist, which writes out Go equivalent for all the
C data structures defined in defs.c.
This in turn makes it necessary to define the Plink type,
used in os_plan9.h, in os_plan9.go. Rename it to _Plink
to avoid being exported.
LGTM=0intro, iant
R=golang-codereviews, iant, 0intro
CC=golang-codereviews, r
https://golang.org/cl/132490043
uintptr is better when translating to Go,
and in a few places it's better in C too.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant, khr
https://golang.org/cl/138980043
This change fixes the last known false negative of the race detector --
detection of races between mutating atomic operations and non-atomic operations.
Race runtime already has functions for precise modelling of various atomic operations,
so this change just forwards all atomic ops to race runtime
instead of poor man modeling in sync/atomic package.
Performance is also improved -- full sync/atomic tests run in 60s instead of 85s now.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/111310044
NO CODE CHANGES HERE
The first conversion was not complete.
This CL doesn't make any actual changes,
but it inserts the missing mprof.goc code
as comments so that the next CL will have
useful diffs.
To make the diffs a bit more useful, removed
all semicolons, ->, and runtime· prefixes as well.
Also corrected order of a few functions in mprof.go
to match original order in mprof.goc.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/134200043
Make the definition of the EpollEvent data field consistent
across architectures, adapt the other use of it in
netpoll_epoll for the new definition, and use uint64 rather
than uintptr.
LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/137890043
We can't translate misaligned things to Go, so start rejecting them in C.
The only one in any build appears to be EpollEvent on linux/amd64.
Fix that.
LGTM=r
R=golang-codereviews, r, dvyukov
CC=golang-codereviews, iant
https://golang.org/cl/137020043
In an earlier CL I wrote a separate Go-only version, but that broke Plan 9,
because the Go-only version assumed a non-Plan 9 system.
Translate the real ones instead.
LGTM=r
R=golang-codereviews, r
CC=0intro, golang-codereviews, iant, khr
https://golang.org/cl/140050044
Under the race detector most of the samples go into race runtime,
because of that freebsd race builder constantly fails on this test.
LGTM=bradfitz, rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews, minux
https://golang.org/cl/133370043
Tested on linux/amd64 too this time.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, iant, rsc
https://golang.org/cl/140050043
In CL 131450043, which raised it to 160,
I'd raise it to 192 if necessary.
Apparently it is necessary on windows/amd64.
One note for those concerned about the growth:
in the old segmented stack world, we wasted this much
space at the bottom of every stack segment.
In the new contiguous stack world, each goroutine has
only one stack segment, so we only waste this much space
once per goroutine. So even raising the limit further might
still be a net savings.
Fixes windows/amd64 build.
TBR=r
CC=golang-codereviews
https://golang.org/cl/132480043
Renaming the C SysAlloc will let Go define a prototype without exporting it.
For use in cpuprof.goc's translation to Go.
LGTM=mdempsky
R=golang-codereviews, mdempsky
CC=golang-codereviews, iant
https://golang.org/cl/140060043
Actually it mostly deletes code -- alg.print and alg.copy go away.
There was only one usage of alg.print for debug purposes.
Alg.copy is used in chan.goc, but Keith replaces them with
memcopy during conversion, so alg.copy is not needed as well.
Converting them would be significant amount of work
for no visible benefit.
LGTM=crawshaw, rsc, khr
R=golang-codereviews, crawshaw, khr
CC=golang-codereviews, rsc
https://golang.org/cl/139930044
It is anyway, just an allocated one.
Giving it a sized type makes Go access nicer.
LGTM=iant
R=dvyukov, iant
CC=golang-codereviews
https://golang.org/cl/139960043
