Keith Randall

Either that, or there is some corruption happening that is overwriting the mutex. I would bet on the latter.

I believe that opcode is only implemented on arm64 and ppc64 so far. It shouldn't be hard to do - we already pad on x86 for various alignment restrictions.

This crash happens early on during compiler startup, before it has even read any of the code to be compiled. In fact, I think the compiler is completely deterministic up...

Both failures are with `-race`, which may implicate the race detector itself or our instrumentation that calls it (e.g. if it messed up live variable stack maps that in turn...

Good point, I don't think the compiler/linker is race-enabled when on a race builder. Just the resulting tests.

Definitely not a great benchmark. With a sub-1ns running time, lots of noise. I think we can probably get rid of it. (Anyone know how to do that? Where's the...

I can reproduce with: ``` package p import ( "testing" ) func BenchmarkAppendMsgReplicateDecision(b *testing.B) { v := ReplicateDecision{} bts := make([]byte, 0, v.Msgsize()) bts, _ = v.MarshalMsg(bts[0:0]) b.SetBytes(int64(len(bts))) b.ReportAllocs() b.ResetTimer()...

Simple repro: ``` package p import ( "testing" ) func BenchmarkFoo(b *testing.B) { s := make([]byte, 1) for i := 0; i < b.N; i++ { s = append(s[:0], 0)...

You're right, it fixes my simple repro but not the original repro.

If we're going to go this route we should do `UnmarshalStream(pb Message, r io.ReadSeeker)`. Then we could use a seeker version of `io.MultiReader` to combine byte streams. (We need seeker...