mem: add `Buffer.Slice()` by ash2k · Pull Request #8977 · grpc/grpc-go

ash2k · 2026-03-17T05:31:10Z

I have a CodecV2 that gives me a mem.BufferSlice (i.e. exposes what it gets from gRPC directly). I need to get another mem.BufferSlice from it that is a subslice. In some scenarios I need to slice the first and/or the last buffer to get only the subset of data. Hence, having a Slice() method on the Buffer type would be really useful.

Another use case: I want to use BufferSlice.Reader and implement a Peek()(or similar) to get a BufferSlice of the next N bytes. I don't want a []byte or [][]byte, I'd like to return this BufferSlice from a codecv2 and let gRPC free the buffers when it no longer needs them (i.e. I don't want to wrap those individual []byte into BufferSlices).

RELEASE NOTES:

mem: add mem.Buffer.Slice() - new method to slice the buffer like a slice.

codecov · 2026-03-17T05:36:36Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.18%. Comparing base (aa4d281) to head (f57d232).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8977      +/-   ##
==========================================
+ Coverage   83.02%   83.18%   +0.15%     
==========================================
  Files         413      413              
  Lines       33229    33249      +20     
==========================================
+ Hits        27589    27658      +69     
+ Misses       4221     4190      -31     
+ Partials     1419     1401      -18

Files with missing lines	Coverage Δ
mem/buffer_slice.go	`96.45% <100.00%> (ø)`
mem/buffers.go	`90.26% <100.00%> (+2.09%)`	⬆️

... and 29 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

arjan-bal

The new API looks good. I left a few minor comments.

I was also planning to introduce something similar in this diff to eliminate the copy performed in bufio.Reader.

Just FYI, the zero-copy buffer struct used in Rust also has a very similar API.

arjan-bal · 2026-03-24T20:33:51Z

Please also merge the master branch to unblock some CI workflows that were changed recently.

ash2k · 2026-03-25T01:28:53Z

@arjan-bal All done!

arjan-bal

LGTM, adding a second reviewer.

easwars · 2026-03-26T22:37:39Z

 }

+func (s) TestBuffer_Slice(t *testing.T) {
+	ready := false


Is the ready bit really required? We only call mem.NewBuffer once. Maybe I'm missing something?

It helps to ensure the buffer is not freed earlier than its safe to do so.

It just feels a little weird to have a value that it set by the test goroutine and the value is checked here in the Put method of the pool. Instead, if you can have a channel that is closed when the Put method is called, or a grpcsync.Event that is fired when the Put method is called, the main test goroutine can do the following:

after the first slice is freed, ensure that the event hasn't fired (or if using a channel, ensure that a read on the channel does not return with a short deadline)

after the second slice is freed, do the same thing

after the root buffer is freed, ensure that the event fires or the channel is closed

Would that work?

The code matches the existing pattern (see freed above). But I've changed it to use a channel.

easwars · 2026-03-26T22:47:30Z

 	}
 }

+func (s) TestBuffer_Slice(t *testing.T) {


Actually, do we need this test at all?

Can't we fold this into TestBuffer_SliceBasic and TestBuffer_SliceSubSlice?

Like, we don't have to check if slice is freed too early by explicitly checking in the ctor. We can let ReadOnlyData detect that.

And similarly, we don't have to check if the buffer is freed explicitly, as long as we use the default buffer pool. The leakchecker will do that for us.

So you're saying we can delete this test? I don't see NewLeakChecker used anywhere.

The leakchecker that I mentioned is implemented here: https://github.com/grpc/grpc-go/tree/master/internal/leakcheck and it gets invoked on all tests.

But I'm fine with leaving this test as is.

easwars · 2026-03-26T22:48:03Z

+	}
+}
+
+func (s) TestBuffer_SliceEmpty(t *testing.T) {


Can we do this test for all ctors as well?

We already have a case for this {0, 0, []byte{}},. I can remove it and instead do it in this test.

Yes, that would be nicer. Thanks.

easwars · 2026-03-26T22:49:10Z

+	}
+	tests := []struct {
+		name       string
+		buf        func() mem.Buffer


Can we use the ctor logic here as well?

Could you elaborate? I'm not sure what you mean.

I wanted to see if we can do something like what we do in the other tests: for _, c := range ctors { ... }

easwars · 2026-03-31T04:29:04Z

+	return mem.SliceBuffer(data)
+}
+
+func newEmptyBuf(_ []byte) mem.Buffer {


Nit: The underscore identifier can be omitted.

easwars · 2026-03-31T04:32:10Z

 	}
 }

+func (s) TestBuffer_Slice(t *testing.T) {


The leakchecker that I mentioned is implemented here: https://github.com/grpc/grpc-go/tree/master/internal/leakcheck and it gets invoked on all tests.

But I'm fine with leaving this test as is.

easwars · 2026-03-31T04:33:08Z

+	}
+}
+
+func (s) TestBuffer_SliceEmpty(t *testing.T) {


Yes, that would be nicer. Thanks.

easwars · 2026-03-31T04:42:42Z

+	}
+	tests := []struct {
+		name       string
+		buf        func() mem.Buffer


I wanted to see if we can do something like what we do in the other tests: for _, c := range ctors { ... }

Works just like Go's slice slicing.

ash2k · 2026-04-03T23:07:53Z

@easwars Thanks for the review! I've addressed the feedback. Please let me know if I missed something.

easwars

Thanks for your contribution!

ash2k force-pushed the ash2k/slice branch from ee6e64c to 14c28f6 Compare March 17, 2026 05:33

ash2k force-pushed the ash2k/slice branch 2 times, most recently from a405abf to 89ce1f0 Compare March 17, 2026 06:16

easwars requested a review from arjan-bal March 24, 2026 03:46

easwars assigned arjan-bal Mar 24, 2026

arjan-bal reviewed Mar 24, 2026

View reviewed changes

Comment thread mem/buffers.go

Comment thread mem/buffers.go Outdated

Comment thread mem/buffers.go

Comment thread mem/buffers_test.go Outdated

Comment thread mem/buffers_test.go Outdated

Comment thread mem/buffers_test.go Outdated

Comment thread mem/buffers_test.go Outdated

arjan-bal assigned ash2k and easwars and unassigned arjan-bal Mar 24, 2026

arjan-bal added this to the 1.81 Release milestone Mar 24, 2026

arjan-bal added the Type: Feature New features or improvements in behavior label Mar 24, 2026

ash2k force-pushed the ash2k/slice branch from 89ce1f0 to fee1b84 Compare March 25, 2026 00:21

arjan-bal assigned arjan-bal and unassigned ash2k Mar 26, 2026

arjan-bal approved these changes Mar 26, 2026

View reviewed changes

arjan-bal removed their assignment Mar 26, 2026

easwars reviewed Mar 26, 2026

View reviewed changes

easwars assigned ash2k and unassigned easwars Mar 26, 2026

Pranjali-2501 assigned easwars and unassigned ash2k Mar 31, 2026

easwars reviewed Mar 31, 2026

View reviewed changes

easwars assigned ash2k and unassigned easwars Mar 31, 2026

ash2k added 3 commits April 4, 2026 10:01

mem: simplify freeFirstBufferIfEmpty

d824a5b

mem: add Buffer.Slice()

f51b986

Works just like Go's slice slicing.

mem: inline assertion helper

3b25289

ash2k added 3 commits April 4, 2026 10:01

mem: swap want/got

e78f1ca

mem: explicitly pass the initial buffer

92134b3

mem: refactor tests

f57d232

ash2k force-pushed the ash2k/slice branch from e06f769 to f57d232 Compare April 3, 2026 23:07

arjan-bal assigned easwars and unassigned ash2k Apr 7, 2026

easwars approved these changes Apr 7, 2026

View reviewed changes

easwars merged commit 5fdb6d0 into grpc:master Apr 7, 2026
14 checks passed

ash2k deleted the ash2k/slice branch April 8, 2026 05:39

ash2k mentioned this pull request May 24, 2026

mem: add Reader.PeekBuffer() #9139

Closed

Conversation

ash2k commented Mar 17, 2026 • edited by arjan-bal Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

arjan-bal left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

arjan-bal commented Mar 24, 2026

Uh oh!

ash2k commented Mar 25, 2026

Uh oh!

arjan-bal left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ash2k Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ash2k commented Apr 3, 2026

Uh oh!

easwars left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ash2k commented Mar 17, 2026 •

edited by arjan-bal

Loading

codecov Bot commented Mar 17, 2026 •

edited

Loading

ash2k Mar 27, 2026 •

edited

Loading