NetBSD and OpenBSD are broken like OS X is. Good to know.
Drop required count from avg/2 to avg/3, because the
Plan 9 builder just barely missed avg/2 in one of its runs.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/12548043
This means that pprof will no longer report profiles on OS X.
That's unfortunate, but the profiles were often wrong and, worse,
it was difficult to tell whether the profile was wrong or not.
The workarounds were making the scheduler more complex,
possibly caused a deadlock (see issue 5519), and did not actually
deliver reliable results.
It may be possible for adventurous users to apply a patch to
their kernels to get working results, or perhaps having no results
will encourage someone to do the work of creating a profiling
thread like on Windows. Issue 6047 has details.
Fixes#5519.
Fixes#6047.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/12429045
until we decide what to do with issues 5659/5736.
Profiling with race detector is not very useful in general,
and now it makes race builders red.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10523043
This is the same logic used in the standard tracebacks.
The caller pc is the pc after the call, so except in the
fake "call" caused by a panic, back up the pc enough
that the lookup will use the previous instruction.
Fixes#4150.
Fixes#4151.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7317047
The profiler collects goroutine blocking information similar to Google Perf Tools.
You may see an example of the profile (converted to svg) attached to
http://code.google.com/p/go/issues/detail?id=3946
The public API changes are:
+pkg runtime, func BlockProfile([]BlockProfileRecord) (int, bool)
+pkg runtime, func SetBlockProfileRate(int)
+pkg runtime, method (*BlockProfileRecord) Stack() []uintptr
+pkg runtime, type BlockProfileRecord struct
+pkg runtime, type BlockProfileRecord struct, Count int64
+pkg runtime, type BlockProfileRecord struct, Cycles int64
+pkg runtime, type BlockProfileRecord struct, embedded StackRecord
R=rsc, dave, minux.ma, r
CC=gobot, golang-dev, r, remyoudompheng
https://golang.org/cl/6443115
Reverts part of CL 6460082.
If a doc comment describes a type by explaining the
meaning of one instance of the type, a leading article
is fine and makes the text less awkward.
Compare:
// A dog is a kind of animal.
// Dog is a kind of animal.
R=golang-dev, dsymonds, dvyukov, r
CC=golang-dev
https://golang.org/cl/6494066
The previous heap profile format did not include buckets with
zero used bytes. Also add several missing MemStats fields in
debug mode.
R=golang-dev, rsc
CC=golang-dev, remy
https://golang.org/cl/6249068
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
Makes it possible for client code to maintain its own profiles,
and also reduces the API surface by giving us a type that
models built-in profiles.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5684056
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
Unexports runtime.MemStats and rename MemStatsType to MemStats.
The new accessor requires passing a pointer to a user-allocated
MemStats structure.
Fixes#2572.
R=bradfitz, rsc, bradfitz, gustavo
CC=golang-dev, remy
https://golang.org/cl/5616072
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
Fixes#1641.
Actually it side steps the real issue, which is that the
setitimer(2) implementation on OS X is not useful for
profiling of multi-threaded programs. I filed the below
using the Apple Bug Reporter.
/*
Filed as Apple Bug Report #9177434.
This program creates a new pthread that loops, wasting cpu time.
In the main pthread, it sleeps on a condition that will never come true.
Before doing so it sets up an interval timer using ITIMER_PROF.
The handler prints a message saying which thread it is running on.
POSIX does not specify which thread should receive the signal, but
in order to be useful in a user-mode self-profiler like pprof or gprof
http://code.google.com/p/google-perftoolshttp://www.delorie.com/gnu/docs/binutils/gprof_25.html
it is important that the thread that receives the signal is the one
whose execution caused the timer to expire.
Linux and FreeBSD handle this by sending the signal to the process's
queue but delivering it to the current thread if possible:
http://lxr.linux.no/linux+v2.6.38/kernel/signal.c#L802
807 /*
808 * Now find a thread we can wake up to take the signal off the queue.
809 *
810 * If the main thread wants the signal, it gets first crack.
811 * Probably the least surprising to the average bear.
812 * /
http://fxr.watson.org/fxr/source/kern/kern_sig.c?v=FREEBSD8;im=bigexcerpts#L1907
1914 /*
1915 * Check if current thread can handle the signal without
1916 * switching context to another thread.
1917 * /
On those operating systems, this program prints:
$ ./a.out
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
signal on cpu-chewing looper thread
$
The OS X kernel does not have any such preference. Its get_signalthread
does not prefer current_thread(), in contrast to the other two systems,
so the signal gets delivered to the first thread in the list that is able to
handle it, which ends up being the main thread in this experiment.
http://fxr.watson.org/fxr/source/bsd/kern/kern_sig.c?v=xnu-1456.1.26;im=excerpts#L1666
$ ./a.out
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
signal on sleeping main thread
$
The fix is to make get_signalthread use the same heuristic as
Linux and FreeBSD, namely to use current_thread() if possible
before scanning the process thread list.
*/
#include <sys/time.h>
#include <sys/signal.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
static void handler(int);
static void* looper(void*);
static pthread_t pmain, ploop;
int
main(void)
{
struct itimerval it;
struct sigaction sa;
pthread_cond_t cond;
pthread_mutex_t mu;
memset(&sa, 0, sizeof sa);
sa.sa_handler = handler;
sa.sa_flags = SA_RESTART;
memset(&sa.sa_mask, 0xff, sizeof sa.sa_mask);
sigaction(SIGPROF, &sa, 0);
pmain = pthread_self();
pthread_create(&ploop, 0, looper, 0);
memset(&it, 0, sizeof it);
it.it_interval.tv_usec = 10000;
it.it_value = it.it_interval;
setitimer(ITIMER_PROF, &it, 0);
pthread_mutex_init(&mu, 0);
pthread_mutex_lock(&mu);
pthread_cond_init(&cond, 0);
for(;;)
pthread_cond_wait(&cond, &mu);
return 0;
}
static void
handler(int sig)
{
static int nsig;
pthread_t p;
p = pthread_self();
if(p == pmain)
printf("signal on sleeping main thread\n");
else if(p == ploop)
printf("signal on cpu-chewing looper thread\n");
else
printf("signal on %p\n", (void*)p);
if(++nsig >= 10)
exit(0);
}
static void*
looper(void *v)
{
for(;;);
}
R=r
CC=golang-dev
https://golang.org/cl/4273113
The old heap maps used a multilevel table, but that
was overkill: there are only 1M entries on a 32-bit
machine and we can arrange to use a dense address
range on a 64-bit machine.
The heap map is in bss. The assumption is that if
we don't touch the pages they won't be mapped in.
Also moved some duplicated memory allocation
code out of the OS-specific files.
R=r
CC=golang-dev
https://golang.org/cl/4118042
