Skip to content

Conversation

@fmstephe
Copy link
Owner

This gives us confidence that these method call don't allocate.

@fmstephe fmstephe force-pushed the test-gcassert branch 2 times, most recently from d78302c to c4478e0 Compare January 17, 2025 10:42
Each of these methods have a pointer receiver. But RefPointer is used as
a value, so it's important that the receiver does not escape to the
heap. If it does escape then each method call(!) will allocate to the
heap.

As a side note, the rationale behind using a pointer receiver is to
avoid copying two words on RefPointer method calls. This rationale makes
sense, but hasn't been tested as a performance improvement. In the
future we should test this. Maybe value receivers are just as good (or
better).
At this time this fork of gcassert detects leaking parameter messages
indicating that a parameter has escaped to the heap.

Remove gcassert if it exists

rm rm

Use version v0.0.3 of my gcassert fork
@fmstephe fmstephe force-pushed the test-gcassert branch 2 times, most recently from 5bad08e to 325af59 Compare January 17, 2025 11:42
Because the handler is passed into a fmt.Errorf(...) call on an error
path the handler is forced to be on the heap. We take the value of the
handler to avoid this.

This error was picked up by the gcassert:noescape annotation. Very
satisfying.
@fmstephe fmstephe merged commit 7ebc721 into master Jan 17, 2025
1 check passed
@fmstephe fmstephe deleted the test-gcassert branch January 17, 2025 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant