cmd/compile: reduce lock/scheduler contention

During the parallel section of compilation, we limit the amount of
parallelism to prevent scheduler churn. We do this with a worker
scheduler, but it does not have insight on when a compilation is blocked
due to lock contention.

The symbol table was protected with a lock. While most lookups were
quick lock->read->unlock affairs, sometimes there would be
initialization logic involved. This caused every lookup to stall,
waiting for init. Since our worker scheduler couldn't see this, it would
not launch new goroutine to "cover" the gap.

Fix by splitting the symbol lock into 2 cases, initialization and
lookup. If symbols need initialization simultaneously, they will wait
for each other, but the common case of looking up a symbol will be
handled by a syncmap. In practice, I have yet to see this lock being
blocked on.

Additionally, get rid of the scheduler goroutine and have each
compilation goroutine grab work from a central queue. When multiple
compilations finished at the same time, the work scheduler would
sometime not get run immediately. This ended up starving the system of
work.

These 2 changes together cuts -1.37% off the build time of typescriptgo
on systems with a lot of cores (specifically, the c3h88 perf builder).

Updates #73044.

Change-Id: I6d4b3be56fd00a4fdd4df132bcbd52e4b2a3e91f
Reviewed-on: https://go-review.googlesource.com/c/go/+/724623
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>

0 files changed, 0 insertions, 0 deletions