runtime: refactor goroutine profilerecord types #132
Closed
+64
−153
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
austinderek
force-pushed
the
master
branch
29 times, most recently
from
385dc33 to
6764046
Compare
austinderek
force-pushed
the
master
branch
29 times, most recently
from
9f3a108 to
c37e118
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 is a mirror of upstream PR golang#76141