@@ -362,49 +362,6 @@ public ByteBufAllocator getDelegate() {
362362 }
363363 }
364364
365- static class TrashingByteBuf extends WrappedByteBuf {
366-
367- private boolean trashed = false ;
368-
369- protected TrashingByteBuf (ByteBuf buf ) {
370- super (buf );
371- }
372-
373- @ Override
374- public boolean release () {
375- if (refCnt () == 1 ) {
376- // see [NOTE on racy trashContent() calls]
377- trashContent ();
378- }
379- return super .release ();
380- }
381-
382- @ Override
383- public boolean release (int decrement ) {
384- if (refCnt () == decrement && refCnt () > 0 ) {
385- // see [NOTE on racy trashContent() calls]
386- trashContent ();
387- }
388- return super .release (decrement );
389- }
390-
391- // [NOTE on racy trashContent() calls]: We trash the buffer content _before_ reducing the ref
392- // count to zero, which looks racy because in principle a concurrent caller could come along
393- // and successfully retain() this buffer to keep it alive after it's been trashed. Such a
394- // caller would sometimes get an IllegalReferenceCountException ofc but that's something it
395- // could handle - see for instance org.elasticsearch.transport.netty4.Netty4Utils.ByteBufRefCounted.tryIncRef.
396- // Yet in practice this should never happen, we only ever retain() these buffers while we
397- // know them to be alive (i.e. via RefCounted#mustIncRef or its moral equivalents) so it'd
398- // be a bug for a caller to retain() a buffer whose ref count is heading to zero and whose
399- // contents we've already decided to trash.
400- private void trashContent () {
401- if (trashed == false ) {
402- trashed = true ;
403- TrashingByteBufAllocator .trashBuffer (buf );
404- }
405- }
406- }
407-
408365 static class TrashingCompositeByteBuf extends CompositeByteBuf {
409366
410367 TrashingCompositeByteBuf (ByteBufAllocator alloc , boolean direct , int maxNumComponents ) {
0 commit comments