Skip to content

Conversation

@niaow
Copy link
Member

@niaow niaow commented May 30, 2020

Previously, chansend and chanrecv allocated a heap object before blocking on a channel. This object was used to implement a linked list of goroutines blocked on the channel. The chansend and chanrecv now instead accept a buffer to store this object in as an argument. The compiler now creates a stack allocation for this object and passes it in.

Fixes #1143

Previously, chansend and chanrecv allocated a heap object before blocking on a channel.
This object was used to implement a linked list of goroutines blocked on the channel.
The chansend and chanrecv now instead accept a buffer to store this object in as an argument.
The compiler now creates a stack allocation for this object and passes it in.
@niaow niaow added the enhancement New feature or request label May 30, 2020
@niaow niaow requested a review from aykevl May 30, 2020 13:05
@niaow niaow linked an issue May 30, 2020 that may be closed by this pull request
@niaow niaow added the next-release Will be part of next release label May 30, 2020
@niaow niaow added this to the v0.14 milestone May 30, 2020
@aykevl
Copy link
Member

aykevl commented Jun 8, 2020

I checked the binary size impact. The only difference was (as expected) for testdata/channel.go, increasing by around 0.6% (wasm, microbit) to 2.5% (amd64). Not too much (and the lack of GC is good), but good to be aware of. Normally such a size impact would be a problem but in normal code channels aren't used nearly as much as in testdata/channel.go. And it brings the advantage that blocking on a channel send/receive won't trigger the GC, which is expensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

runtime: chansend and chanrecv operations should not allocate

3 participants