Skip to content

AdaptiveByteBufAllocator: make sure byteBuf.capacity() not greater th…#16320

Merged
chrisvest merged 1 commit intonetty:4.1from
chrisvest:4.1-maxFastCapacity
Feb 21, 2026
Merged

AdaptiveByteBufAllocator: make sure byteBuf.capacity() not greater th…#16320
chrisvest merged 1 commit intonetty:4.1from
chrisvest:4.1-maxFastCapacity

Conversation

@chrisvest
Copy link
Copy Markdown
Member

…an byteBuf.maxCapacity() (#16309)

Motivation:

According to the docs of ByteBuf.maxCapacity():

/**
* Returns the maximum allowed capacity of this buffer. This value provides an upper
* bound on {@link #capacity()}.
*/
public abstract int maxCapacity();

The byteBuf.capacity() should always <= byteBuf.maxCapacity().

But if we run the following code:

public static void main(String[] args) {
    int maxSize = 100000;
    AdaptiveByteBufAllocator alloc = new AdaptiveByteBufAllocator();
    ByteBuf buf = alloc.newDirectBuffer(maxSize, maxSize);
    System.out.println("Before reallocation: buf.capacity(): " + buf.capacity());
    System.out.println("Before reallocation: buf.maxCapacity(): " + buf.maxCapacity());
    buf = buf.capacity(maxSize + 1); // Should not be allowed.
    System.out.println("After reallocation: buf.capacity(): " + buf.capacity());
    System.out.println("After reallocation: buf.maxCapacity(): " + buf.maxCapacity());
    //assert buf.capacity() <= buf.maxCapacity();
}

The output:

Before reallocation: buf.capacity(): 100000
Before reallocation: buf.maxCapacity(): 100000
After reallocation: buf.capacity(): 100001
After reallocation: buf.maxCapacity(): 100000

We can see after reallocation, the buf.capacity() is greater than buf.maxCapacity(), which should not happen.

Modification:

Adjust the check in AdaptivePoolingAllocator.capacity(int newCapacity), to make sure the constrain hold.

Result:

Make sure byteBuf.capacity() not greater than byteBuf.maxCapacity().


Co-authored-by: lao

(cherry picked from commit a78ea77)

…an byteBuf.maxCapacity() (netty#16309)

Motivation:

According to the docs of `ByteBuf.maxCapacity()`:

https://github.com/netty/netty/blob/d9336245a2fe3dfec4d0d1e489135bbf7ed03160/buffer/src/main/java/io/netty/buffer/ByteBuf.java#L265-L269

The `byteBuf.capacity()` should always <= `byteBuf.maxCapacity()`.

But if we run the following code:
```
public static void main(String[] args) {
    int maxSize = 100000;
    AdaptiveByteBufAllocator alloc = new AdaptiveByteBufAllocator();
    ByteBuf buf = alloc.newDirectBuffer(maxSize, maxSize);
    System.out.println("Before reallocation: buf.capacity(): " + buf.capacity());
    System.out.println("Before reallocation: buf.maxCapacity(): " + buf.maxCapacity());
    buf = buf.capacity(maxSize + 1); // Should not be allowed.
    System.out.println("After reallocation: buf.capacity(): " + buf.capacity());
    System.out.println("After reallocation: buf.maxCapacity(): " + buf.maxCapacity());
    //assert buf.capacity() <= buf.maxCapacity();
}
```
The output:

> Before reallocation: buf.capacity(): 100000
> Before reallocation: buf.maxCapacity(): 100000
> After reallocation: buf.capacity(): 100001
> After reallocation: buf.maxCapacity(): 100000

We can see after reallocation, the `buf.capacity()` is greater than
`buf.maxCapacity()`, which should not happen.

Modification:

Adjust the check in `AdaptivePoolingAllocator.capacity(int
newCapacity)`, to make sure the constrain hold.

Result:

Make sure `byteBuf.capacity()` not greater than `byteBuf.maxCapacity()`.

---------

Co-authored-by: lao <none>

(cherry picked from commit a78ea77)
@chrisvest chrisvest added this to the 4.1.132.Final milestone Feb 20, 2026
@chrisvest chrisvest enabled auto-merge (squash) February 20, 2026 23:21
@chrisvest chrisvest merged commit 27a66a4 into netty:4.1 Feb 21, 2026
18 checks passed
@chrisvest chrisvest deleted the 4.1-maxFastCapacity branch February 21, 2026 04:15
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.

2 participants