Skip to content

AdaptivePoolingAllocator: assign a more explicit value to BuddyChunk.freeListCapacity#16334

Merged
chrisvest merged 5 commits into
netty:4.2from
laosijikaichele:4.2-freeListCapacity
Feb 25, 2026
Merged

AdaptivePoolingAllocator: assign a more explicit value to BuddyChunk.freeListCapacity#16334
chrisvest merged 5 commits into
netty:4.2from
laosijikaichele:4.2-freeListCapacity

Conversation

@laosijikaichele

Copy link
Copy Markdown
Contributor

Motivation:

Currently, the value of BuddyChunk.freeListCapacity is less than the real max size of the freeList.

  1. It may lead to the freeList.drain(freeListCapacity, this) can not drain all the elements at once.
  2. When calling MpscIntQueue.create(freeListCapacity, -1), we rely on MpscIntQueue implicitly calling MathUtil.safeFindNextPositivePowerOfTwo(freeListCapacity) to set the proper max size. This makes the code less explicit.
  3. Semantically, freeListCapacity should be equal to the value of capFactor, if I understand correctly.
  4. In addition, use freeListCapacity = capFactor eliminates a bit-shift operation.

Modification:

Use freeListCapacity = capFactor; instead of freeListCapacity = tree >> 1;.

Result:

More clean code.

@chrisvest

Copy link
Copy Markdown
Member

The buddies array is a binary search tree, where claiming a branch node prevents the claiming of all child nodes of the branch. The maximum number of entries that could be freed at any one time is half the tree, which would happen if you claimed all the leaf nodes and then freed them.

@chrisvest

Copy link
Copy Markdown
Member

In other words, the existing code should be correct.

@chrisvest chrisvest closed this Feb 23, 2026
@chrisvest chrisvest reopened this Feb 23, 2026

@chrisvest chrisvest left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually the difference is just 1, and as you say the queue will call MathUtil.safeFindNextPositivePowerOfTwo to bump it by one.

We can remove the tree variable entirely and inline capFactor. That would be a better cleanup to do.

@chrisvest chrisvest added this to the 4.2.11.Final milestone Feb 25, 2026
@chrisvest chrisvest added needs-cherry-pick-4.1 This PR should be cherry-picked to 4.1 once merged. needs-cherry-pick-5.0 This PR should be cherry-picked to 5.0 once merged. labels Feb 25, 2026
@chrisvest chrisvest merged commit b7ec449 into netty:4.2 Feb 25, 2026
16 of 19 checks passed
@netty-project-bot

Copy link
Copy Markdown
Contributor

Could not create auto-port PR.
Got conflicts when cherry-picking onto 4.1.

chrisvest pushed a commit to chrisvest/netty that referenced this pull request Feb 25, 2026
…freeListCapacity (netty#16334)

Motivation:

Currently, the value of `BuddyChunk.freeListCapacity` is less than the
real max size of the `freeList`.
1. It may lead to the `freeList.drain(freeListCapacity, this)` can not
drain all the elements at once.
2. When calling `MpscIntQueue.create(freeListCapacity, -1)`, we rely on
`MpscIntQueue` implicitly calling
`MathUtil.safeFindNextPositivePowerOfTwo(freeListCapacity)` to set the
proper max size. This makes the code less explicit.
3. Semantically, `freeListCapacity` should be equal to the value of
`capFactor`, if I understand correctly.
4. In addition, use `freeListCapacity = capFactor` eliminates a
bit-shift operation.

Modification:

Use `freeListCapacity = capFactor;` instead of `freeListCapacity = tree
>> 1;`.

Result:

More clean code.

---------

Co-authored-by: lao <none>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>

(cherry picked from commit b7ec449)
@chrisvest

Copy link
Copy Markdown
Member

Backport PR for 4.1: #16368

@chrisvest chrisvest removed the needs-cherry-pick-4.1 This PR should be cherry-picked to 4.1 once merged. label Feb 25, 2026
netty-project-bot pushed a commit that referenced this pull request Feb 25, 2026
…freeListCapacity (#16334)

Motivation:

Currently, the value of `BuddyChunk.freeListCapacity` is less than the
real max size of the `freeList`.
1. It may lead to the `freeList.drain(freeListCapacity, this)` can not
drain all the elements at once.
2. When calling `MpscIntQueue.create(freeListCapacity, -1)`, we rely on
`MpscIntQueue` implicitly calling
`MathUtil.safeFindNextPositivePowerOfTwo(freeListCapacity)` to set the
proper max size. This makes the code less explicit.
3. Semantically, `freeListCapacity` should be equal to the value of
`capFactor`, if I understand correctly.
4. In addition, use `freeListCapacity = capFactor` eliminates a
bit-shift operation.

Modification:

Use `freeListCapacity = capFactor;` instead of `freeListCapacity = tree
>> 1;`.

Result:

More clean code.

---------

Co-authored-by: lao <none>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>
(cherry picked from commit b7ec449)
@netty-project-bot

Copy link
Copy Markdown
Contributor

Auto-port PR for 5.0: #16369

@github-actions github-actions Bot removed the needs-cherry-pick-5.0 This PR should be cherry-picked to 5.0 once merged. label Feb 25, 2026
chrisvest added a commit that referenced this pull request Feb 26, 2026
… to BuddyChunk.freeListCapacity (#16369)

Auto-port of #16334 to 5.0
Cherry-picked commit: b7ec449

---
Motivation:

Currently, the value of `BuddyChunk.freeListCapacity` is less than the
real max size of the `freeList`.
1. It may lead to the `freeList.drain(freeListCapacity, this)` can not
drain all the elements at once.
2. When calling `MpscIntQueue.create(freeListCapacity, -1)`, we rely on
`MpscIntQueue` implicitly calling
`MathUtil.safeFindNextPositivePowerOfTwo(freeListCapacity)` to set the
proper max size. This makes the code less explicit.
3. Semantically, `freeListCapacity` should be equal to the value of
`capFactor`, if I understand correctly.
4. In addition, use `freeListCapacity = capFactor` eliminates a
bit-shift operation.

Modification:

Use `freeListCapacity = capFactor;` instead of `freeListCapacity = tree
>> 1;`.

Result:

More clean code.

Co-authored-by: old driver <29225782+laosijikaichele@users.noreply.github.com>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>
chrisvest added a commit that referenced this pull request Feb 26, 2026
…freeListCapacity (#16334) (#16368)

Motivation:

Currently, the value of `BuddyChunk.freeListCapacity` is less than the
real max size of the `freeList`.
1. It may lead to the `freeList.drain(freeListCapacity, this)` can not
drain all the elements at once.
2. When calling `MpscIntQueue.create(freeListCapacity, -1)`, we rely on
`MpscIntQueue` implicitly calling
`MathUtil.safeFindNextPositivePowerOfTwo(freeListCapacity)` to set the
proper max size. This makes the code less explicit.
3. Semantically, `freeListCapacity` should be equal to the value of
`capFactor`, if I understand correctly.
4. In addition, use `freeListCapacity = capFactor` eliminates a
bit-shift operation.

Modification:

Use `freeListCapacity = capFactor;` instead of `freeListCapacity = tree
>> 1;`.

Result:

More clean code.

---------

Co-authored-by: lao <none>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>

(cherry picked from commit b7ec449)

Co-authored-by: old driver <29225782+laosijikaichele@users.noreply.github.com>
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.

3 participants