From 258295676b4b6a3fa3fbf9cd065dd0c58e2ada3f Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.ohly@intel.com>
Date: Thu, 2 Feb 2023 19:56:02 +0100
Subject: [PATCH] buffer: restore dropping of too large buffers

This was removed when introducing sync.Pool in commit
1a1367cc64e28f8bf3dcc04cd74010cc67bdd57d because it seemed unnecessary, but an
open issue about the sync.Pool documentation shows that a size limit may be
useful after all.
---
 internal/buffer/buffer.go | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/internal/buffer/buffer.go b/internal/buffer/buffer.go
index d53b49da..fc9df1d7 100644
--- a/internal/buffer/buffer.go
+++ b/internal/buffer/buffer.go
@@ -55,6 +55,17 @@ func GetBuffer() *Buffer {
 
 // PutBuffer returns a buffer to the free list.
 func PutBuffer(b *Buffer) {
+	if b.Len() >= 256 {
+		// Let big buffers die a natural death, without relying on
+		// sync.Pool behavior. The documentation implies that items may
+		// get deallocated while stored there ("If the Pool holds the
+		// only reference when this [= be removed automatically]
+		// happens, the item might be deallocated."), but
+		// https://github.com/golang/go/issues/23199 leans more towards
+		// having such a size limit.
+		return
+	}
+
 	buffers.Put(b)
 }