1
0
mirror of https://github.com/golang/go synced 2024-10-04 02:31:22 -06:00
Commit Graph

121 Commits

Author SHA1 Message Date
Russ Cox
2e4a035995 runtime: do not handle signals before configuring handler
There was a small window during program initialization
where a signal could come in before the handling mechanisms
were set up to handle it.  Delay the signal-handler installation
until we're ready for the signals.

Fixes #3314.

R=golang-dev, dsymonds, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5833049
2012-03-15 22:17:54 -04:00
Russ Cox
9e5db8c90a 5l, 6l, 8l: fix stack split logic for stacks near default segment size
Fixes #3310.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5823051
2012-03-15 15:22:30 -04:00
Rémy Oudompheng
aa1aaee7fd runtime: wait for main goroutine before setting GOMAXPROCS.
Fixes #3182.

R=golang-dev, dvyukov, rsc
CC=golang-dev, remy
https://golang.org/cl/5732057
2012-03-05 16:40:27 -05:00
Russ Cox
dc159fabff runtime: run init on main thread
Fixes #3125.

R=golang-dev, r, minux.ma
CC=golang-dev
https://golang.org/cl/5714049
2012-03-01 11:48:17 -05:00
Russ Cox
6e2ae0a12c runtime/pprof: support OS X CPU profiling
Work around profiling kernel bug with signal masks.
Still broken on 64-bit Snow Leopard kernel,
but I think we can ignore that one and let people
upgrade to Lion.

Add new trivial tools addr2line and objdump to take
the place of the GNU tools of the same name, since
those are not installed on OS X.

Adapt pprof to invoke 'go tool addr2line' and
'go tool objdump' if the system tools do not exist.

Clean up disassembly of base register on amd64.

Fixes #2008.

R=golang-dev, bradfitz, mikioh.mikioh, r, iant
CC=golang-dev
https://golang.org/cl/5697066
2012-02-28 16:18:24 -05:00
Russ Cox
e4b02bfdc0 runtime: goroutine profile, stack dumps
R=golang-dev, r, r
CC=golang-dev
https://golang.org/cl/5687076
2012-02-22 21:45:01 -05:00
Russ Cox
8a4c2b3cc4 runtime: fix another memory leak
morebuf holds a pc/sp from the last stack split or
reflect.call or panic/recover.  If the pc is a closure,
the reference will keep it from being collected.

moreargp holds a pointer to the arguments from the
last stack split or reflect.call or panic/recover.
Normally it is a stack pointer and thus not of interest,
but in the case of reflect.call it is an allocated argument
list and holds up the arguments to the call.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5674109
2012-02-19 11:05:19 -05:00
Russ Cox
89b075cc90 runtime: fix tiny memory leak
The m->cret word holds the C return value when returning
across a stack split boundary.  It was not being cleared after
use, which means that the return value (if a C function)
or else the value of AX/R0 at the time of the last stack unsplit
was being kept alive longer than necessary.  Clear it.

I think the effect here should be very small, but worth fixing
anyway.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5677092
2012-02-19 00:26:33 -05:00
David Symonds
4b171e5040 runtime: rename Cgocalls and Goroutines to NumCgoCall and NumGoroutine, respectively.
Update some other docs too.

Update #2955.

R=rsc
CC=golang-dev
https://golang.org/cl/5676060
2012-02-17 08:49:41 +11:00
Sébastien Paolacci
5c598d3c9f runtime: release unused memory to the OS.
Periodically browse MHeap's freelists for long unused spans and release them if any.

Current hardcoded settings:
        - GC is forced if none occured over the last 2 minutes.
        - spans are handed back after 5 minutes of uselessness.

SysUnused (for Unix) is a wrapper on madvise MADV_DONTNEED on Linux and MADV_FREE on BSDs.

R=rsc, dvyukov, remyoudompheng
CC=golang-dev
https://golang.org/cl/5451057
2012-02-16 13:30:04 -05:00
Russ Cox
1707a9977f runtime: on 386, fix FP control word on all threads, not just initial thread
It is possible that Linux and Windows copy the FP control word
from the parent thread when creating a new thread.  Empirically,
Darwin does not.  Reset the FP control world in all cases.

Enable the floating-point strconv test.

Fixes #2917 (again).

R=golang-dev, r, iant
CC=golang-dev
https://golang.org/cl/5660047
2012-02-14 01:23:15 -05:00
Russ Cox
5b93fc9da6 runtime, pprof: add profiling of thread creation
Same idea as heap profile: how did each thread get created?
Low memory (256 bytes per OS thread), high reward for
programs that suddenly have many threads running.

Fixes #1477.

R=golang-dev, r, dvyukov
CC=golang-dev
https://golang.org/cl/5639059
2012-02-08 10:33:54 -05:00
Damian Gryski
8e765da941 runtime: add runtime.cputicks() and seed fastrand with it
This patch adds a function to get the current cpu ticks.  This is
deemed to be 'sufficiently random' to use to seed fastrand to mitigate
the algorithmic complexity attacks on the hash table implementation.

On AMD64 we use the RDTSC instruction.  For 386, this instruction,
while valid, is not recognized by 8a so I've inserted the opcode by
hand.  For ARM, this routine is currently stubbed to return a constant
0 value.

Future work: update 8a to recognize RDTSC.

Fixes #2630.

R=rsc
CC=golang-dev
https://golang.org/cl/5606048
2012-02-02 14:09:27 -05:00
Russ Cox
851f30136d runtime: make more build-friendly
Collapse the arch,os-specific directories into the main directory
by renaming xxx/foo.c to foo_xxx.c, and so on.

There are no substantial edits here, except to the Makefile.
The assumption is that the Go tool will #define GOOS_darwin
and GOARCH_amd64 and will make any file named something
like signals_darwin.h available as signals_GOOS.h during the
build.  This replaces what used to be done with -I$(GOOS).

There is still work to be done to make runtime build with
standard tools, but this is a big step.  After this we will have
to write a script to generate all the generated files so they
can be checked in (instead of generated during the build).

R=r, iant, r, lucio.dere
CC=golang-dev
https://golang.org/cl/5490053
2011-12-16 15:33:58 -05:00
Russ Cox
0acd879c26 syscall: take over env implementation
The environment is needed by package time, which
we want not to depend on os (so that os can use
time.Time), so push down into syscall.

Delete syscall.Sleep, now unnecessary.

The package os environment API is preserved;
it is only the implementation that is moving to syscall.

Delete os.Envs, which was undocumented,
uninitialized on Windows and Plan 9, and
not maintained by Setenv and Clearenv.
Code can call os.Environ instead.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5370091
2011-11-14 14:06:50 -05:00
Ian Lance Taylor
3f2d787c2b runtime: remove declarations of nonexistent functions
R=rsc, r
CC=golang-dev
https://golang.org/cl/5369089
2011-11-11 14:30:27 -08:00
Russ Cox
3b860269ee runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.

It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another.  (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)

Fixes #1644.
Fixes #1731.
Fixes #2190.

R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
Ian Lance Taylor
4ac425fcdd runtime: add comments for various functions in proc.c
R=rsc
CC=golang-dev
https://golang.org/cl/5357047
2011-11-08 18:16:25 -08:00
Alex Brainman
b776b9e724 runtime: add windows callback tests
Just a copy of cgo callback tests from misc/cgo/test.

R=rsc
CC=golang-dev, hectorchu
https://golang.org/cl/5331062
2011-11-08 16:53:31 +11:00
Russ Cox
6808da0163 runtime: lock the main goroutine to the main OS thread during init
We only guarantee that the main goroutine runs on the
main OS thread for initialization.  Programs that wish to
preserve that property for main.main can call runtime.LockOSThread.
This is what programs used to do before we unleashed
goroutines during init, so it is both a simple fix and keeps
existing programs working.

R=iant, r, dave, dvyukov
CC=golang-dev
https://golang.org/cl/5309070
2011-10-27 18:04:12 -07:00
Hector Chu
2572ca2ff2 runtime: include bootstrap m in mcpu accounting
R=rsc, dvyukov
CC=golang-dev
https://golang.org/cl/5307052
2011-10-25 08:35:20 +01:00
Russ Cox
d1bafffa4b runtime: run goroutines during init
Fixes #583.
Fixes #1776.
Fixes #2001.
Fixes #2112.

R=golang-dev, bradfitz, r, gri
CC=golang-dev
https://golang.org/cl/5265044
2011-10-13 15:54:23 -04:00
Dmitriy Vyukov
5695915833 runtime: fix spurious deadlock reporting
Fixes #2337.
Unfortunate sequence of events is:
1. maxcpu=2, mcpu=1, grunning=1
2. starttheworld creates an extra M:
   maxcpu=2, mcpu=2, grunning=1
4. the goroutine calls runtime.GOMAXPROCS(1)
   maxcpu=1, mcpu=2, grunning=1
5. since it sees mcpu>maxcpu, it calls gosched()
6. schedule() deschedules the goroutine:
   maxcpu=1, mcpu=1, grunning=0
7. schedule() call getnextandunlock() which
   fails to pick up the goroutine again,
   because canaddcpu() fails, because mcpu==maxcpu
8. then it sees that grunning==0,
   reports deadlock and terminates

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5191044
2011-10-06 18:10:14 +03:00
Hector Chu
85916146ea runtime: fix usleep on linux/386 and re-enable parallel gc
R=golang-dev, jsing, alex.brainman, cw, rsc
CC=golang-dev
https://golang.org/cl/5166047
2011-10-03 19:08:59 +01:00
Russ Cox
f18e4e44a3 runtime: disable parallel gc
Breaks on Linux/386 during parallel sync tests.

TBR=r
CC=golang-dev
https://golang.org/cl/5168044
2011-09-30 14:59:46 -04:00
Russ Cox
d324f2143b runtime: parallelize garbage collector mark + sweep
Running test/garbage/parser.out.

On a 4-core Lenovo X201s (Linux):
31.12u 0.60s 31.74r 	 1 cpu, no atomics
32.27u 0.58s 32.86r 	 1 cpu, atomic instructions
33.04u 0.83s 27.47r 	 2 cpu

On a 16-core Xeon (Linux):
33.08u 0.65s 33.80r 	 1 cpu, no atomics
34.87u 1.12s 29.60r 	 2 cpu
36.00u 1.87s 28.43r 	 3 cpu
36.46u 2.34s 27.10r 	 4 cpu
38.28u 3.85s 26.92r 	 5 cpu
37.72u 5.25s 26.73r	 6 cpu
39.63u 7.11s 26.95r	 7 cpu
39.67u 8.10s 26.68r	 8 cpu

On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5):
39.43u 1.45s 41.27r 	 1 cpu, no atomics
43.98u 2.95s 38.69r 	 2 cpu

On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1):
48.81u 2.12s 51.76r 	 1 cpu, no atomics
57.15u 4.72s 51.54r 	 2 cpu

The handoff algorithm is really only good for two cores.
Beyond that we will need to so something more sophisticated,
like have each core hand off to the next one, around a circle.
Even so, the code is a good checkpoint; for now we'll limit the
number of gc procs to at most 2.

R=dvyukov
CC=golang-dev
https://golang.org/cl/4641082
2011-09-30 09:40:01 -04:00
Russ Cox
33e9d24ad9 runtime: fix void warnings
Add -V flag to 6c command line to keep them fixed.

R=ken2
CC=golang-dev
https://golang.org/cl/4930046
2011-08-23 13:13:27 -04:00
Russ Cox
03e9ea5b74 runtime: simplify stack traces
Make the stack traces more readable for new
Go programmers while preserving their utility for old hands.

- Change status number [4] to string.
- Elide frames in runtime package (internal details).
- Swap file:line and arguments.
- Drop 'created by' for main goroutine.
- Show goroutines in order of allocation:
  implies main goroutine first if nothing else.

There is no option to get the extra frames back.
Uncomment 'return 1' at the bottom of symtab.c.

$ 6.out
throw: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
       /Users/rsc/g/go/src/pkg/runtime/x.go:22 +0x8a

goroutine 2 [select (no cases)]:
main.sel()
       /Users/rsc/g/go/src/pkg/runtime/x.go:11 +0x18
created by main.main
       /Users/rsc/g/go/src/pkg/runtime/x.go:19 +0x23

goroutine 3 [chan receive]:
main.recv(0xf8400010a0, 0x0)
       /Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
       /Users/rsc/g/go/src/pkg/runtime/x.go:20 +0x50

goroutine 4 [chan receive (nil chan)]:
main.recv(0x0, 0x0)
       /Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
       /Users/rsc/g/go/src/pkg/runtime/x.go:21 +0x66
$

$ 6.out index
panic: runtime error: index out of range

goroutine 1 [running]:
main.main()
        /Users/rsc/g/go/src/pkg/runtime/x.go:25 +0xb9
$

$ 6.out nil
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x22ca]

goroutine 1 [running]:
main.main()
        /Users/rsc/g/go/src/pkg/runtime/x.go:28 +0x211
$

$ 6.out panic
panic: panic

goroutine 1 [running]:
main.main()
        /Users/rsc/g/go/src/pkg/runtime/x.go:30 +0x101
$

R=golang-dev, qyzhai, n13m3y3r, r
CC=golang-dev
https://golang.org/cl/4907048
2011-08-22 23:26:39 -04:00
Ian Lance Taylor
7bbe2c8998 runtime: Remove extraneous word in comment.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/4938045
2011-08-22 12:40:45 -07:00
Alex Brainman
72e83483a7 runtime: speed up cgo calls
Allocate Defer on stack during cgo calls, as suggested
by dvyukov. Also includes some comment corrections.

benchmark                   old,ns/op   new,ns/op
BenchmarkCgoCall                  669         330
(Intel Xeon CPU 1.80GHz * 4, Linux 386)

R=dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4910041
2011-08-18 12:17:09 -04:00
Dmitriy Vyukov
a2677cf363 runtime: fix GC bitmap corruption
The corruption can occur when GOMAXPROCS
is changed from >1 to 1, since GOMAXPROCS=1
does not imply there is only 1 goroutine running,
other goroutines can still be not parked after
the change.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4873050
2011-08-16 16:53:02 -04:00
Hector Chu
6500065543 runtime: remove unnecessary locking
R=rsc, dvyukov
CC=golang-dev
https://golang.org/cl/4819051
2011-08-04 00:22:39 -04:00
Hector Chu
9bc58accce runtime: fix scheduling race
Affects programs using cgo or runtime.LockOSThread.

Fixes #2100.

R=rsc, dvyukov
CC=golang-dev
https://golang.org/cl/4810059
2011-07-29 17:39:02 -04:00
Russ Cox
100a034120 runtime: higher goroutine arg limit, clearer error
Fixes #591.

R=ken2
CC=golang-dev
https://golang.org/cl/4803054
2011-07-27 12:41:46 -04:00
Russ Cox
ba134539c5 runtime: faster entersyscall/exitsyscall
Replace cas with xadd in scheduler.
Suggested by Dmitriy in last code review.
Verified with Promela model.

When there's actual contention for the atomic word,
this avoids the looping that compare-and-swap requires.

benchmark                            old ns/op    new ns/op    delta
runtime_test.BenchmarkSyscall               32           26  -17.08%
runtime_test.BenchmarkSyscall-2            155           59  -61.81%
runtime_test.BenchmarkSyscall-3            112           52  -52.95%
runtime_test.BenchmarkSyscall-4             94           48  -48.57%
runtime_test.BenchmarkSyscallWork          871          872   +0.11%
runtime_test.BenchmarkSyscallWork-2        481          477   -0.83%
runtime_test.BenchmarkSyscallWork-3        338          335   -0.89%
runtime_test.BenchmarkSyscallWork-4        263          256   -2.66%

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/4800047
2011-07-23 12:22:55 -04:00
Dmitriy Vyukov
d6ed1b70ad runtime: replace centralized ncgocall counter with a distributed one
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4809042
2011-07-21 11:29:08 -04:00
Russ Cox
025abd530e runtime: faster entersyscall, exitsyscall
Uses atomic memory accesses to avoid the need to acquire
and release schedlock on fast paths.

benchmark                            old ns/op    new ns/op    delta
runtime_test.BenchmarkSyscall               73           31  -56.63%
runtime_test.BenchmarkSyscall-2            538           74  -86.23%
runtime_test.BenchmarkSyscall-3            508          103  -79.72%
runtime_test.BenchmarkSyscall-4            721           97  -86.52%
runtime_test.BenchmarkSyscallWork          920          873   -5.11%
runtime_test.BenchmarkSyscallWork-2        516          481   -6.78%
runtime_test.BenchmarkSyscallWork-3        550          343  -37.64%
runtime_test.BenchmarkSyscallWork-4        632          263  -58.39%

(Intel Core i7 L640 2.13 GHz-based Lenovo X201s)

Reduced a less artificial server benchmark
from 11.5r 12.0u 8.0s to 8.3r 9.1u 1.0s.

R=dvyukov, r, bradfitz, r, iant, iant
CC=golang-dev
https://golang.org/cl/4723042
2011-07-19 11:01:17 -04:00
Russ Cox
bd77619142 runtime: track running goroutine count
Used to use mcpu+msyscall but that's
problematic for packing into a single
atomic word.  The running goroutine count
(where running == Go code or syscall)
can be maintained separately, always
manipulated under lock.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/4767041
2011-07-18 15:50:55 -04:00
Quan Yong Zhai
fe9991e8b2 runtime: replace runtime.mcpy with runtime.memmove
faster string operations, and more

tested on linux/386

runtime_test.BenchmarkSliceToString                    642          532  -17.13%
runtime_test.BenchmarkStringToSlice                    636          528  -16.98%
runtime_test.BenchmarkConcatString                    1109          897  -19.12%

R=r, iant, rsc
CC=golang-dev
https://golang.org/cl/4674042
2011-07-12 17:30:40 -07:00
Dmitriy Vyukov
86e7323bdf runtime: eliminate false sharing during stack growth
Remove static variable from runtime·oldstack().
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows (with CL 4657091 applied):
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1183.00      1180.00   -0.25%
BenchmarkStackGrowth-2                             1249.00      1211.00   -3.04%
BenchmarkStackGrowth-4                              954.00       805.00  -15.62%
BenchmarkStackGrowth-8                              701.00       683.00   -2.57%
BenchmarkStackGrowth-16                             465.00       415.00  -10.75%

R=rsc
CC=golang-dev
https://golang.org/cl/4693042
2011-07-12 10:56:21 -07:00
Russ Cox
88e0c0517a runtime: fix comment (lost in shuffle)
TBR=dvyukov
CC=golang-dev
https://golang.org/cl/4710041
2011-07-12 09:26:05 -07:00
Dmitriy Vyukov
c9152a8568 runtime: eliminate contention during stack allocation
Standard-sized stack frames use plain malloc/free
instead of centralized lock-protected FixAlloc.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1045.00       949.00   -9.19%
BenchmarkStackGrowth-2                             3450.00       800.00  -76.81%
BenchmarkStackGrowth-4                             5076.00       513.00  -89.89%
BenchmarkStackGrowth-8                             7805.00       471.00  -93.97%
BenchmarkStackGrowth-16                           11751.00       321.00  -97.27%

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4657091
2011-07-12 09:24:32 -07:00
Dmitriy Vyukov
013ad89c9b runtime: eliminate false sharing on runtime.goidgen
runtime.goidgen can be quite frequently modified and
shares cache line with the following variables,
it leads to false sharing.
50c6b0 b nfname
50c6b4 b nfunc
50c6b8 b nfunc$17
50c6bc b nhist$17
50c6c0 B runtime.checking
50c6c4 B runtime.gcwaiting
50c6c8 B runtime.goidgen
50c6cc B runtime.gomaxprocs
50c6d0 B runtime.panicking
50c6d4 B strconv.IntSize
50c6d8 B src/pkg/runtime/_xtest_.ss
50c6e0 B src/pkg/runtime/_xtest_.stop
50c6e8 b addrfree
50c6f0 b addrmem
50c6f8 b argv

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4673054
2011-07-12 01:25:14 -04:00
Dmitriy Vyukov
909f31872a runtime: eliminate false sharing on random number generators
Use machine-local random number generator instead of
racy global ones.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4674049
2011-07-12 01:23:58 -04:00
Wei Guangjing
f83609f642 runtime: windows/amd64 port
R=rsc, alex.brainman, hectorchu, r
CC=golang-dev
https://golang.org/cl/3759042
2011-06-29 17:37:56 +10:00
Alexey Borzenkov
b701cf3332 runtime: make StackSystem part of StackGuard
Fixes #1779

R=rsc
CC=golang-dev
https://golang.org/cl/4543052
2011-05-16 16:57:49 -04:00
Brad Fitzpatrick
623e7de187 os: make Setenv update C environment variables
Fixes #1569

R=rsc, bradfitzwork
CC=golang-dev
https://golang.org/cl/4456045
2011-05-02 12:38:13 -07:00
Russ Cox
370276a3e5 runtime: stack split + garbage collection bug
The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).

That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls.  Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.

The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp.  In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number.  Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory.  On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number.  Scanblock would not scan anything, possibly
causing in-use blocks to be freed.

In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.

Fixes #1620.
Fixes #1746.

R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
2011-04-27 23:21:12 -04:00
Dmitriy Vyukov
29d78f1243 runtime: fix GOMAXPROCS vs garbage collection bug
Fixes #1715.

R=golang-dev, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4434053
2011-04-21 12:09:25 -04:00
Russ Cox
c19b373c8a runtime: cpu profiling support
R=r
CC=golang-dev
https://golang.org/cl/4306043
2011-03-23 11:43:37 -04:00