| //go:build grpcgoid |
| // +build grpcgoid |
| |
| /* |
| * |
| * Copyright 2019 gRPC authors. |
| * |
| * Licensed under the Apache License, Version 2.0 (the "License"); |
| * you may not use this file except in compliance with the License. |
| * You may obtain a copy of the License at |
| * |
| * http://www.apache.org/licenses/LICENSE-2.0 |
| * |
| * Unless required by applicable law or agreed to in writing, software |
| * distributed under the License is distributed on an "AS IS" BASIS, |
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| * See the License for the specific language governing permissions and |
| * limitations under the License. |
| * |
| */ |
| |
| package profiling |
| |
| import ( |
| "runtime" |
| ) |
| |
| // This stubbed function usually returns zero (see goid_regular.go); however, |
| // if grpc is built with `-tags 'grpcgoid'`, a runtime.Goid function, which |
| // does not exist in the Go standard library, is expected. While not necessary, |
| // sometimes, visualising grpc profiling data in trace-viewer is much nicer |
| // with goroutines separated from each other. |
| // |
| // Several other approaches were considered before arriving at this: |
| // |
| // 1. Using a CGO module: CGO usually has access to some things that regular |
| // Go does not. Till go1.4, CGO used to have access to the goroutine struct |
| // because the Go runtime was written in C. However, 1.5+ uses a native Go |
| // runtime; as a result, CGO does not have access to the goroutine structure |
| // anymore in modern Go. Besides, CGO interop wasn't fast enough (estimated |
| // to be ~170ns/op). This would also make building grpc require a C |
| // compiler, which isn't a requirement currently, breaking a lot of stuff. |
| // |
| // 2. Using runtime.Stack stacktrace: While this would remove the need for a |
| // modified Go runtime, this is ridiculously slow, thanks to the all the |
| // string processing shenanigans required to extract the goroutine ID (about |
| // ~2000ns/op). |
| // |
| // 3. Using Go version-specific build tags: For any given Go version, the |
| // goroutine struct has a fixed structure. As a result, the goroutine ID |
| // could be extracted if we know the offset using some assembly. This would |
| // be faster then #1 and #2, but is harder to maintain. This would require |
| // special Go code that's both architecture-specific and go version-specific |
| // (a quadratic number of variants to maintain). |
| // |
| // 4. This approach, which requires a simple modification [1] to the Go runtime |
| // to expose the current goroutine's ID. This is the chosen approach and it |
| // takes about ~2 ns/op, which is negligible in the face of the tens of |
| // microseconds that grpc takes to complete a RPC request. |
| // |
| // [1] To make the goroutine ID visible to Go programs apply the following |
| // change to the runtime2.go file in your Go runtime installation: |
| // |
| // diff --git a/src/runtime/runtime2.go b/src/runtime/runtime2.go |
| // --- a/src/runtime/runtime2.go |
| // +++ b/src/runtime/runtime2.go |
| // @@ -392,6 +392,10 @@ type stack struct { |
| // hi uintptr |
| // } |
| // |
| // +func Goid() int64 { |
| // + return getg().goid |
| // +} |
| // + |
| // type g struct { |
| // // Stack parameters. |
| // // stack describes the actual stack memory: [stack.lo, stack.hi). |
| // |
| // The exposed runtime.Goid() function will return a int64 goroutine ID. |
| func goid() int64 { |
| return runtime.Goid() |
| } |