Skip to content

Causalprof #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8,825 commits into
base: master
Choose a base branch
from
Open

Causalprof #1

wants to merge 8,825 commits into from

Conversation

DanielMorsing
Copy link
Owner

No description provided.

DanielMorsing pushed a commit that referenced this pull request Jun 17, 2018
Every time I see an error that begins `missing argument for Fprintf("%s")`
my mental type-checker goes off, since obviously "%s" is not a valid first
argument to Fprintf. Writing Printf("%s") to report an error in Printf("hello %s")
is almost as confusing.

This CL rewords the errors reported by vet's printf check to be more
consistent with each other, avoid placing context like "in printf call"
in the middle of the message, and to avoid the imprecisions above by
not quoting the format string at all.

Before:

	bad.go:9: no formatting directive in Printf call
	bad.go:10: missing argument for Printf("%s"): format reads arg 1, have only 0 args
	bad.go:11: wrong number of args for format in Printf call: 1 needed but 2 args
	bad.go:12: bad syntax for printf argument index: [1]
	bad.go:13: index value [0] for Printf("%[0]s"); indexes start at 1
	bad.go:14: missing argument for Printf("%[2]s"): format reads arg 2, have only 1 args
	bad.go:15: bad syntax for printf argument index: [abc]
	bad.go:16: unrecognized printf verb 'z'
	bad.go:17: arg "hello" for * in printf format not of type int
	bad.go:18: arg fmt.Sprint in printf call is a function value, not a function call
	bad.go:19: arg fmt.Sprint in Print call is a function value, not a function call
	bad.go:20: arg "world" for printf verb %d of wrong type: string
	bad.go:21: missing argument for Printf("%q"): format reads arg 2, have only 1 args
	bad.go:22: first argument to Print is os.Stderr
	bad.go:23: Println call ends with newline
	bad.go:32: arg r in Sprint call causes recursive call to String method
	bad.go:34: arg r for printf causes recursive call to String method

After:

	bad.go:9: Printf call has arguments but no formatting directives
	bad.go:10: Printf format %s reads arg #1, but have only 0 args
	bad.go:11: Printf call needs 1 args but has 2 args
	bad.go:12: Printf format %[1 is missing closing ]
	bad.go:13: Printf format has invalid argument index [0]
	bad.go:14: Printf format has invalid argument index [2]
	bad.go:15: Printf format has invalid argument index [abc]
	bad.go:16: Printf format %.234z has unknown verb z
	bad.go:17: Printf format %.*s uses non-int "hello" as argument of *
	bad.go:18: Printf format %s arg fmt.Sprint is a func value, not called
	bad.go:19: Print arg fmt.Sprint is a func value, not called
	bad.go:20: Printf format %d has arg "world" of wrong type string
	bad.go:21: Printf format %q reads arg golang#2, but have only 1 args
	bad.go:22: Print does not take io.Writer but has first arg os.Stderr
	bad.go:23: Println args end with redundant newline
	bad.go:32: Sprint arg r causes recursive call to String method
	bad.go:34: Sprintf format %s with arg r causes recursive String method call

Change-Id: I5719f0fb9f2cd84df8ad4c7754ab9b79c691b060
Reviewed-on: https://go-review.googlesource.com/74352
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
bxq2011hust and others added 27 commits January 10, 2020 15:22
Change-Id: Ic7997d1f747152afec78e8e439770166029f34ec
GitHub-Last-Rev: 6a07f25
GitHub-Pull-Request: golang#36491
Reviewed-on: https://go-review.googlesource.com/c/go/+/214298
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This imports CL 213880.

Fixes golang#35511

Change-Id: I55d18713bdac8fa556ba5a2aced922f80d1ac970
Reviewed-on: https://go-review.googlesource.com/c/go/+/214078
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When adjustTimers sees a timerModifiedEarlier or timerModifiedLater,
it removes it from the heap, leaving a new timer at that position
in the heap. We were accidentally skipping that new timer in our loop.
In some unlikely cases this could cause adjustTimers to look at more
timers than necessary.

Change-Id: Ic71e54c175ab7d86a7fa46f1497aca71ed1c43cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/214338
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This pulls in two new commits: a fix for a test broken on plan9 and a
correction to a comment.

Change-Id: I31cf046a5073872714c758894732b2fcc800ab6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/214289
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make file names consistent, using only forward slashes in the path.

Fixes golang#36495

Change-Id: I337119d6dff233ab9d4bfe757147ec25961ae021
Reviewed-on: https://go-review.googlesource.com/c/go/+/214286
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We had a few test cases to make sure checkptr didn't have certain
false positives, but none to test for any true positives. This CL
fixes that.

Updates golang#22218.

Change-Id: I24c02e469a4af43b1748829a9df325ce510f7cc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/214238
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Updates golang#36489

Change-Id: I1ca215ba0a64a31d662134385b8be46bb4ba4434
Reviewed-on: https://go-review.googlesource.com/c/go/+/214282
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Whenever more than 1/4 of the timers on a P's heap are deleted,
remove them from the heap.

Change-Id: Iff63ed3d04e6f33ffc5c834f77f645c52c007e52
Reviewed-on: https://go-review.googlesource.com/c/go/+/214299
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The comment contained a link that had a file name and ID that no longer existed, so change to the URL of the corresponding part of the latest page.

Change-Id: I74e0885aabf470facc39b84035f7a83fef9c6a8e
GitHub-Last-Rev: 5681c84
GitHub-Pull-Request: golang#36514
Reviewed-on: https://go-review.googlesource.com/c/go/+/214181
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change the type printer to take a map of types that we're currently
printing. When we happen upon a type that we're already in the middle
of printing, print a reference to it instead.

A reference to another type is built using the offset of the first
byte of that type's string representation in the result. To facilitate
that computation (and it's probably more efficient, regardless), we
print the type to a buffer as we go, and build the string at the end.

It would be nice to use string.Builder instead of bytes.Buffer, but
string.Builder wasn't around in Go 1.4, and we'd like to bootstrap
from that version.

Fixes golang#29312

Change-Id: I49d788c1fa20f770df7b2bae3b9979d990d54803
Reviewed-on: https://go-review.googlesource.com/c/go/+/214239
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes golang#36375

Change-Id: I407a1db23868880b83e73bc136d274659483fb69
Reviewed-on: https://go-review.googlesource.com/c/go/+/214437
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes golang#36526.

Change-Id: Ic51a287579f139422cc1a7b2fb82d6732114b031
Reviewed-on: https://go-review.googlesource.com/c/go/+/214597
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since Durations only span 290 years, they are not good for
manipulating very remote times. I bounced off this problem recently
while doing some astronomical calculations and it took me a while to
realize I could get a 64-bit seconds value from time.Time.Unix and
subtract two of them to evaluate the interval.

I thought it worth adding a sentence to make this clear. It didn't
occur to me for quite a while that "Unix time" spans a huge range in
the Go library.

Change-Id: I76c75dc951dfd6bcf86e8b0be3cfec518a3ecdee
Reviewed-on: https://go-review.googlesource.com/c/go/+/213977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This reverts CL 214437.

Does not fix the issue, and the test was wrong so it did not detect that it did not fix the issue.

Updates golang#36375

Change-Id: I6a4112035a1e90f4fdafed6fdf4ec9dfc718b571
Reviewed-on: https://go-review.googlesource.com/c/go/+/214601
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Even though I contributed to golang/go[^1], the rule[^2] did not reflect my name in CONTRIBUTORS, so I added it.

[^1]: https://go-review.googlesource.com/c/go/+/164199
[^2]: https://github.com/golang/build/blob/e21a90b/cmd/updatecontrib/updatecontrib.go#L118

Change-Id: I5d6b5684d61ea5da679519a9e703d977470de175
Reviewed-on: https://go-review.googlesource.com/c/go/+/214617
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, the scavenger is paced according to how long it takes to
scavenge one runtime page's worth of memory. However, this pacing
doesn't take into account the additional cost of actually using a
scavenged page. This operation, "sysUsed," is a counterpart to the
scavenging operation "sysUnused." On most systems this operation is a
no-op, but on some systems like Darwin and Windows we actually make a
syscall. Even on systems where it's a no-op, the cost is implicit: a
more expensive page fault when re-using the page.

On Darwin in particular the cost of "sysUnused" is fairly close to the
cost of "sysUsed", which skews the pacing to be too fast. A lot of
soon-to-be-allocated memory ends up scavenged, resulting in many more
expensive "sysUsed" operations, ultimately slowing down the application.

The way to fix this problem is to include the future cost of "sysUsed"
on a page in the scavenging cost. However, measuring the "sysUsed" cost
directly (like we do with "sysUnused") on most systems is infeasible
because we would have to measure the cost of the first access.

Instead, this change applies a multiplicative constant to the measured
scavenging time which is based on a per-system ratio of "sysUnused" to
"sysUsed" costs in the worst case (on systems where it's a no-op, we
measure the cost of the first access). This ultimately slows down the
scavenger to a more reasonable pace, limiting its impact on performance
but still retaining the memory footprint improvements from the previous
release.

Fixes golang#36507.

Change-Id: I050659cd8cdfa5a32f5cc0b56622716ea0fa5407
Reviewed-on: https://go-review.googlesource.com/c/go/+/214517
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This reduces lock contention when only a few P's are running and
checking for whether they need to run timers on the sleeping P's.
Without this change the running P's would get lock contention
while looking at the sleeping P's timers. With this change a single
atomic load suffices to determine whether there are any ready timers.

Change-Id: Ie843782bd56df49867a01ecf19c47498ec827452
Reviewed-on: https://go-review.googlesource.com/c/go/+/214185
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
The HTML linter 'tidy' reports:

	go_spec.html:2556: Warning: unescaped & which should be written as &amp;
	go_spec.html:3293: Warning: unescaped & or unknown entity "&s1"
	go_spec.html:3293: Warning: unescaped & or unknown entity "&a"
	go_spec.html:3294: Warning: unescaped & or unknown entity "&s2"
	go_spec.html:3294: Warning: unescaped & or unknown entity "&a"
	go_spec.html:2045: Warning: trimming empty <p>
	go_spec.html:4526: Warning: trimming empty <ul>
	go_spec.html:4533: Warning: trimming empty <ul>
	go_spec.html:4539: Warning: trimming empty <ul>

This CL fixes all but the <ul> ones, which I think should be fixed
but are defended by a comment.

Change-Id: I0ca88f5e80755024801877ab1298025ecf8f10c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/214457
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Change-Id: I83f806e76ef4d268b187bd273d78ceb41b7e8fa5
GitHub-Last-Rev: ee82eaa
GitHub-Pull-Request: golang#36194
Reviewed-on: https://go-review.googlesource.com/c/go/+/211799
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes golang#36520

Change-Id: I698ab235f82f7c81caa09318c954847cf3833153
GitHub-Last-Rev: 368a1dc
GitHub-Pull-Request: golang#36559
Reviewed-on: https://go-review.googlesource.com/c/go/+/214821
Reviewed-by: Robert Griesemer <gri@golang.org>
Go 1.14 will drop support for macOS 10.10, see golang#23011

This reverts CL 155097

Updates golang#26475
Updates golang#29340

Change-Id: I64d0275141407313b73068436ee81d13eacc4c76
Reviewed-on: https://go-review.googlesource.com/c/go/+/214058
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Based on riscv-go port.

Updates golang#27532

Change-Id: Id8ae7d851c393ec3702e4176c363accb0a42587f
Reviewed-on: https://go-review.googlesource.com/c/go/+/204633
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I noticed this leak while writing CL 214977.

Change-Id: I7566952b8e4bc58939d23435aea86576fc58ddca
Reviewed-on: https://go-review.googlesource.com/c/go/+/214978
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 214239 improved type printing, but introduced performance regressions:
3-5% memory increase, 1-2% CPU time increase.

There were two primary sources of the memory regression:

* allocating a bytes.Buffer for every type to print
* always printing to that buffer, even when we could return a constant string

This change addresses both of those regressions.
The sync.Pool allows buffer re-use.
String interning prevents allocation for re-used strings.

It addresses some, but not all, of the CPU time regression.


Memory performance impact vs master:

name        old alloc/op      new alloc/op      delta
Template         37.6MB ± 0%       36.3MB ± 0%  -3.30%  (p=0.008 n=5+5)
Unicode          28.7MB ± 0%       28.3MB ± 0%  -1.55%  (p=0.008 n=5+5)
GoTypes           127MB ± 0%        122MB ± 0%  -4.38%  (p=0.008 n=5+5)
Compiler          584MB ± 0%        568MB ± 0%  -2.72%  (p=0.008 n=5+5)
SSA              1.99GB ± 0%       1.95GB ± 0%  -1.97%  (p=0.008 n=5+5)
Flate            23.5MB ± 0%       22.8MB ± 0%  -2.84%  (p=0.008 n=5+5)
GoParser         29.2MB ± 0%       28.0MB ± 0%  -4.17%  (p=0.008 n=5+5)
Reflect          81.9MB ± 0%       78.6MB ± 0%  -4.09%  (p=0.008 n=5+5)
Tar              35.3MB ± 0%       34.1MB ± 0%  -3.29%  (p=0.008 n=5+5)
XML              45.5MB ± 0%       44.3MB ± 0%  -2.61%  (p=0.008 n=5+5)
[Geo mean]       82.4MB            79.9MB       -3.09%

name        old allocs/op     new allocs/op     delta
Template           394k ± 0%         363k ± 0%  -7.73%  (p=0.008 n=5+5)
Unicode            340k ± 0%         329k ± 0%  -3.25%  (p=0.008 n=5+5)
GoTypes           1.41M ± 0%        1.28M ± 0%  -9.54%  (p=0.008 n=5+5)
Compiler          5.77M ± 0%        5.39M ± 0%  -6.58%  (p=0.008 n=5+5)
SSA               19.1M ± 0%        18.1M ± 0%  -5.13%  (p=0.008 n=5+5)
Flate              247k ± 0%         228k ± 0%  -7.50%  (p=0.008 n=5+5)
GoParser           325k ± 0%         295k ± 0%  -9.24%  (p=0.008 n=5+5)
Reflect           1.04M ± 0%        0.95M ± 0%  -8.48%  (p=0.008 n=5+5)
Tar                365k ± 0%         336k ± 0%  -7.93%  (p=0.008 n=5+5)
XML                449k ± 0%         417k ± 0%  -7.10%  (p=0.008 n=5+5)
[Geo mean]         882k              818k       -7.26%


Memory performance going from 52c4488,
which is the commit preceding CL 214239, to this change:

name        old alloc/op      new alloc/op      delta
Template         36.5MB ± 0%       36.3MB ± 0%  -0.37%  (p=0.008 n=5+5)
Unicode          28.3MB ± 0%       28.3MB ± 0%  -0.06%  (p=0.008 n=5+5)
GoTypes           123MB ± 0%        122MB ± 0%  -0.64%  (p=0.008 n=5+5)
Compiler          571MB ± 0%        568MB ± 0%  -0.51%  (p=0.008 n=5+5)
SSA              1.96GB ± 0%       1.95GB ± 0%  -0.13%  (p=0.008 n=5+5)
Flate            22.8MB ± 0%       22.8MB ± 0%    ~     (p=0.421 n=5+5)
GoParser         28.1MB ± 0%       28.0MB ± 0%  -0.37%  (p=0.008 n=5+5)
Reflect          78.8MB ± 0%       78.6MB ± 0%  -0.32%  (p=0.008 n=5+5)
Tar              34.3MB ± 0%       34.1MB ± 0%  -0.35%  (p=0.008 n=5+5)
XML              44.3MB ± 0%       44.3MB ± 0%  +0.05%  (p=0.032 n=5+5)
[Geo mean]       80.1MB            79.9MB       -0.27%

name        old allocs/op     new allocs/op     delta
Template           372k ± 0%         363k ± 0%  -2.46%  (p=0.008 n=5+5)
Unicode            333k ± 0%         329k ± 0%  -0.97%  (p=0.008 n=5+5)
GoTypes           1.33M ± 0%        1.28M ± 0%  -3.71%  (p=0.008 n=5+5)
Compiler          5.53M ± 0%        5.39M ± 0%  -2.50%  (p=0.008 n=5+5)
SSA               18.3M ± 0%        18.1M ± 0%  -1.22%  (p=0.008 n=5+5)
Flate              234k ± 0%         228k ± 0%  -2.44%  (p=0.008 n=5+5)
GoParser           305k ± 0%         295k ± 0%  -3.23%  (p=0.008 n=5+5)
Reflect            980k ± 0%         949k ± 0%  -3.12%  (p=0.008 n=5+5)
Tar                345k ± 0%         336k ± 0%  -2.69%  (p=0.008 n=5+5)
XML                425k ± 0%         417k ± 0%  -1.72%  (p=0.008 n=5+5)
[Geo mean]         838k              818k       -2.41%


Remaining CPU time regression, that is,
the change from before CL 214239 to this change:

name        old time/op       new time/op       delta
Template          208ms ± 2%        209ms ± 1%    ~     (p=0.181 n=47+46)
Unicode          82.9ms ± 2%       81.9ms ± 2%  -1.25%  (p=0.000 n=50+48)
GoTypes           709ms ± 3%        714ms ± 3%  +0.77%  (p=0.003 n=48+49)
Compiler          3.31s ± 2%        3.32s ± 2%    ~     (p=0.271 n=48+48)
SSA               10.8s ± 1%        10.9s ± 1%  +0.61%  (p=0.000 n=46+47)
Flate             134ms ± 2%        134ms ± 1%  +0.41%  (p=0.002 n=48+46)
GoParser          166ms ± 2%        167ms ± 2%  +0.41%  (p=0.010 n=46+48)
Reflect           440ms ± 4%        444ms ± 4%  +1.05%  (p=0.002 n=50+49)
Tar               183ms ± 2%        184ms ± 2%    ~     (p=0.074 n=45+45)
XML               247ms ± 2%        248ms ± 2%  +0.67%  (p=0.001 n=49+48)
[Geo mean]        425ms             427ms       +0.34%

name        old user-time/op  new user-time/op  delta
Template          271ms ± 2%        271ms ± 2%    ~     (p=0.654 n=48+48)
Unicode           117ms ± 2%        116ms ± 3%    ~     (p=0.458 n=47+45)
GoTypes           952ms ± 3%        963ms ± 2%  +1.11%  (p=0.000 n=48+49)
Compiler          4.50s ± 5%        4.49s ± 7%    ~     (p=0.894 n=50+50)
SSA               15.0s ± 2%        15.1s ± 2%  +0.46%  (p=0.015 n=50+49)
Flate             166ms ± 2%        167ms ± 2%  +0.40%  (p=0.005 n=49+48)
GoParser          202ms ± 2%        203ms ± 2%  +0.60%  (p=0.002 n=49+47)
Reflect           583ms ± 3%        588ms ± 3%  +0.82%  (p=0.001 n=49+46)
Tar               223ms ± 2%        224ms ± 2%  +0.37%  (p=0.046 n=48+46)
XML               310ms ± 2%        311ms ± 2%  +0.46%  (p=0.009 n=50+49)
[Geo mean]        554ms             556ms       +0.36%


Change-Id: I85951a6538373ef4309a2cc366cc1ebaf1f4582d
Reviewed-on: https://go-review.googlesource.com/c/go/+/214818
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Fixes golang#36557

Change-Id: Ia8125f382d5e14e5612da811268a58971cc9ac08
Reviewed-on: https://go-review.googlesource.com/c/go/+/214917
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Austin Clements <austin@google.com>
Fixes golang#31651

Change-Id: Idbab0c4355fcc58520e210126795223435cf0078
Reviewed-on: https://go-review.googlesource.com/c/go/+/214822
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In CL 199821, we stopped setting the module directory for vendored
packages when -mod=vendor is used. This broke -trimpath, since we
replace the module directory with a string derived from the module
path and version. A comment in CL 202977 makes it clear that the
module directory should not be set.

With this change, -trimpath falls back to replacing the package
directory with the package path if the module directory is not set. We
also fall back to replacing the package directory if the module
version is not set to avoid adding a meaningless @ only for the main
module.

As a consequence of this change, file names in vendored packages will
not have module versions, so file names will be a little different
between -mod=mod and -mod=vendor.

Fixes golang#36566

Change-Id: I0e9cd76d36a2028a49d0b6697ea9a9b3140d7ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/214945
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Change-Id: Ic7b39f4422669ed284ccf0a1b8f8238d6511d134
This makes it so that sleeps executed are adjusted based on how sleeps
were scheduled earlier.

This makes all the results I have way less impressive, but good
none-the-less

Now that I have this info, try logging to see how badly the timer
goroutine introduces lag

Change-Id: I55feef92e75732c0c254df06b8869ac1be958c55
Change-Id: I118ebcd3830548f6fefcf9bfa7c3d528af871cd3
The original causal profiling paper uses several null experiments to
guard against skew. Do the same here.

Change-Id: I63e8edc6dd10ced234622e9a429c4781b23ed42a
Change-Id: I71bb940c98fd883a29ea52aaa8cebd3500838d9e
fixed deadlock when stopping profiling as well.

Change-Id: I1b5bc663e524ae0ef2c3d5aa93f941a2ebf419ba
You could deadlock the system before if you managed to wait inside
the start function.

Also, clear out the cpu channel at all times.

Change-Id: I713c907f3f534e90c5910cc385d53ed7565943aa
Change-Id: I2c7dcc0969123ac74e46a068e95f95e597b107e6
Change-Id: I13f26f6d1eab6dd450c81b15e5dfc834b09fda1b
Change-Id: I3e7cbe6d8b9a5d232c6d490932a04ab21e7e3319
Change-Id: I00feac56ac3d00ec0a937d70d655a6d6bee49178
Change-Id: Ic7522eb5f22cb0ed9088118b6fc8332fbff10cb0
Change-Id: Ia91a6833dbf29f4b43d602fbf05b79f816a49a18
Since dropg is only ever called on the g0, it simplifies the locking
around Ps. It also catches the case where someone called runtime.Sched

Change-Id: Ie06fdcc0c67f655ab586199269f522ece712b068
These were outside the scope of profiling since they interacted
with the scheduler weirdly, but with the new M based sleep, these
exceptions don't matter

Change-Id: I62b9f7efacb9fc78e0a60bbec00631709d178708
Make sure we always do them on a system stack where Ps cannot move

Change-Id: I2187c649172e837c2e99e752ffc002b47561ded2
Change-Id: I5c3d89c2911ba5771c120acbaaa69807d672005d
When a syscall is executed, the M might reclaim an idle P when
returning. Effectively, that can mean that the G gets moved from one
P to another. Hence, we need to mark the G as having been executed
with the delay and pick up on the G if we come back from a syscall
with an idle P.

Change-Id: I86e8bb9e93589b7c580b6709e6941845af116949
This optimization was spurious, since a P being delayed means fewer
opportunities to schedule.
Stop people reading stuff in the tealeaves
Change-Id: Ic7c8f0ec7346b712ced0f55e0d474f270edfd69f
Change-Id: Iaac6792dad5358159260c5ee0d7aa7693ff3fcf7
Change-Id: I4d1f3abb1e5a65e917cde660e911bff3d25d74f4
This should make it more obvious when there's a split between CPU
time spent and speed of program

Change-Id: I00ec5559755799f4a883bdc047e621f8136a2b60
@coxley
Copy link

coxley commented Nov 13, 2024

Just wanted to pop in after reading your HTTP/2 blog post and say this is wicked cool. ❤️ I'd never heard of causal profiling before, and seeing it in practice as someone who looks at pprofs multiple times a day is awesome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.