Updated release notes.

Author: VladSaiocUber

doc/next/4-runtime.md

@@ -2,12 +2,14 @@
 
 ### Goroutine leak profiles {#goroutineleak-profiles}
 
-We introduce a new profile type for goroutine leaks. With the experimental
-flag set to `GOEXPERIMENT=goroutineleakprofile`, it becomes accessible
-through `pprof` under the name `"goroutineleak"`.
+A new profile type that reports leaked goroutines is now available as an
+experiment. The new profile type, named `goroutineleak` in the [runtime/pprof]
+package, may be enabled by setting `GOEXPERIMENT=goroutineleakprofile`
+at build time. Enabling the experiment also makes the profile available
+as a [net/http/pprof] endpoint, `debug/pprof/goroutineleak`.
 
-The following snippet showcases a common, but erroneous pattern
-that leads to goroutine leaks:
+The following example showcases a real-world goroutine leak that
+can be revealed by the new profile:
 ```go
 type result struct{
 		res workResult
@@ -37,27 +39,27 @@ func processWorkItems(ws []workItem) ([]workResult, error) {
 	return results, nil
 }
 ```
-Because `ch` is unbuffered, if `processWorkItems` returns early due to an error,
-all remaining work item goroutines will leak.
-However, also note that, soon after the leak occurs, `ch` is inaccessible
-to any other goroutine, except those involved in the leak.
-
-To generalize, a goroutine is leaked if it is blocked by concurrency
-primitives (specifically channels, and `sync` primitives such as mutex) that
-are only referenced by the blocked goroutine itself, or other leaked goroutines.
-The Go runtime is now equipped to reveal leaked goroutines by recording their stacks in
-goroutine leak profiles.
-In the example above, the stacks of work item goroutines point to the culprit channel send
-operation.
-
-Note that, while goroutine leak profiles only include true positives, goroutine leaks may be
-missed when caused by concurrency primitives that are accessible globally, or referenced
-by runnable goroutines.
+Because `ch` is unbuffered, if `processWorkItems` returns early due to
+an error, all remaining `processWorkItem` goroutines will leak.
+However, `ch` also becomes inaccessible to all other goroutines
+not involved in the leak soon after the leak itself occurs.
+
+In general, a goroutine is leaked if it is blocked on an operation
+over concurrency primitives (e.g., channels,
+[sync.Mutex]) that are only reachable via leaked goroutines.
+In the example above, the culprit channel send operation involves
+a channel only reachable to `processWorkItem` goroutines.
+The runtime is now equipped to detect such leaks via goroutine
+leak profiles. All leaks reported by profiles are real, i.e.,
+there are no false positives.
+
+Note, however, that the runtime may fail to identify leaks caused by
+blocking on operations over concurrency primitives reachable
+through global variables or the local variables of runnable goroutines.
 
 Special thanks to Vlad Saioc at Uber for contributing this work.
 The underlying theory is presented in detail by Saioc et al. in [this publication](https://dl.acm.org/doi/pdf/10.1145/3676641.3715990).
 
-<!-- More details about the implementation are presented in the [design document](https://github.com/golang/proposal/blob/master/design/74609-goroutine-leak-detection-gc.md). -->
 We encourage users to try out the new feature with examples derived from known patterns in [the Go playground](https://go.dev/play/p/3C71z4Dpav-?v=gotip),
 as well as experiment with different environments (tests, CI, production).
 We welcome feedback on the [proposal issue](https://github.com/golang/go/issues/74609).