Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not store non-pointer values in sync.Pool. #4089

Merged
merged 3 commits into from
Oct 4, 2019

Conversation

martinmr
Copy link
Contributor

@martinmr martinmr commented Sep 27, 2019

A sync.Pool is used to avoid unnecessary allocations and reduce the
amount of work the garbage collector has to do. When passing a value
that is not a pointer to a function that accepts an interface, the value
needs to be placed on the heap, which means an additional allocation.
Slices are a common thing to put in sync.Pools, and they’re structs with
3 fields (length, capacity, and a pointer to an array). In order to
avoid the extra allocation, one should store a pointer to the slice
instead.


This change is Reviewable

A sync.Pool is used to avoid unnecessary allocations and reduce the
amount of work the garbage collector has to do.  When passing a value
that is not a pointer to a function that accepts an interface, the value
needs to be placed on the heap, which means an additional allocation.
Slices are a common thing to put in sync.Pools, and they’re structs with
3 fields (length, capacity, and a pointer to an array). In order to
avoid the extra allocation, one should store a pointer to the slice
instead.
Copy link

@pullrequest pullrequest bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ A review job has been created and sent to the PullRequest network.


@martinmr you can click here to see the review status or cancel the code review job.

@martinmr martinmr requested a review from a team September 27, 2019 22:17
Copy link

@pullrequest pullrequest bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change is pretty straightforward but this code is assuming that 100% of the time that route will be populated and we will never attempt to reference a nil pointer.

That can be a source of a lot of future issues if you don't create some assertion whenever this struct is created and used (that it'll always be there).

I would lean towards:

  • adding some defensive programming to check whether the field is populated before accessing it OR
  • ensuring that there is always a non-nil pointer populated in the struct at all times.

Reviewed with ❤️ by PullRequest

Copy link
Contributor Author

@martinmr martinmr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added an extra check.

Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @pawanrawal)

@martinmr martinmr merged commit 155a958 into master Oct 4, 2019
@martinmr martinmr deleted the martinmr/sync-pool-pointer branch October 4, 2019 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant