runtime: refactor goroutine profilerecord types #76141
Conversation
Previously, goroutine profiles were collected into two adjacent slices each of length n, with the i'th index of the first holding the captured stack of the i'th goroutine and the i'th index of the second holding its captured labels. This changes the representation used during collection to be a single slice of length n, with the stack and labels of the i'th goroutine now residing in two fields of each struct in that slice. Switching from multiple slices each of a single attribute each to one slice of multiple attributes avoids allocating multiple slices, as well as needing to pass them both around, side-by-side, in all goroutine profile collection code. While maintaining and passing two slices was workable -- if perhaps slightly cumbersome -- passing side-by-side around would quickly become unwieldy if or when any additional attributes such as wait reasons or wait times are collected during goroutine profiling, for example as proposed in golang#74954. Regardless of the user-facing shape that any such extension to goroutine profiling may end up taking, this updated internal representation should be substantially easier to extend and maintain than side-by-side slices. This is a pure refactor of this internal representation; it should have no user-facing behavior change. While in the area: concurrent goroutine collection has been the only mechanism used for some time now, so the disused legacy implementation goroutineProfileWithLabelsSync is removed and the single remaining implementation is renamed to drop its 'concurrent' qualifier. Updates golang#74954. Change-Id: I3fd14834b2f3aae73317d3fad3294d539302713f
|
This PR (HEAD: 0ae59d2) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/go/+/717020. Important tips:
|
|
Message from Gopher Robot: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/717020. |
|
Message from Gopher Robot: Patch Set 1: Congratulations on opening your first change. Thank you for your contribution! Next steps: Most changes in the Go project go through a few rounds of revision. This can be During May-July and Nov-Jan the Go project is in a code freeze, during which Please don’t reply on this GitHub thread. Visit golang.org/cl/717020. |
2 participants
Previously, goroutine profiles were collected into two adjacent slices each of length n, with the i'th index of the first holding the captured stack of the i'th goroutine and the i'th index of the second holding its captured labels.
This changes the representation used during collection to be a single slice of length n, with the stack and labels of the i'th goroutine now residing in two fields of each struct in that slice.
Switching from multiple slices each of a single attribute each to one slice of multiple attributes avoids allocating multiple slices, as well as needing to pass them both around, side-by-side, in all goroutine profile collection code. While maintaining and passing two slices was workable -- if perhaps slightly cumbersome -- passing side-by-side around would quickly become unwieldy if or when any additional attributes such as wait reasons or wait times are collected during goroutine profiling, for example as proposed in #74954.
Regardless of the user-facing shape that any such extension to goroutine profiling may end up taking, this updated internal representation should be substantially easier to extend and maintain than side-by-side slices.
This is a pure refactor of this internal representation; it should have no user-facing behavior change.
While in the area: concurrent goroutine collection has been the only mechanism used for some time now, so the disused legacy implementation goroutineProfileWithLabelsSync is removed and the single remaining implementation is renamed to drop its 'concurrent' qualifier.
Updates #74954.
Change-Id: I3fd14834b2f3aae73317d3fad3294d539302713f