Skip to content

Always prefer direct buffers for pooled allocators if not explicit di…#15232

Merged
normanmaurer merged 1 commit into4.2from
prefer_direct_buffers_pooled
May 22, 2025
Merged

Always prefer direct buffers for pooled allocators if not explicit di…#15232
normanmaurer merged 1 commit into4.2from
prefer_direct_buffers_pooled

Conversation

@normanmaurer
Copy link
Copy Markdown
Member

…sabled

Motivation:

We should always prefer direct buffers if the ByteBufAllocator implementations are pooled as deallocating these buffers should be rare.

Modifications:

  • Add new method to PlatformDependent that can be used to check if default direct buffer usage was explicit disabled
  • Use this method in our pooled ByteBufAllocator implementations to check if we should use direct buffers or not by default

Result:

Less memory copies and better performance when using the pooled allocators even if Unsafe can not be used.

Copy link
Copy Markdown
Contributor

@franz1981 franz1981 left a comment

Choose a reason for hiding this comment

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

We could even wait till @chrisvest changes are merged and consider safe to always use direct ones only if the cleaner won't delay freeing up them e.g. Unsafe and FFM versions.
This will make a more elastic and effective ergonomics

@normanmaurer
Copy link
Copy Markdown
Member Author

@franz1981 maybe... I think this change might still be a good one even without what @chrisvest did. Especially when thinking about 4.1

…sabled

Motivation:

We should always prefer direct buffers if the ByteBufAllocator implementations are pooled as deallocating these buffers should be rare.

Modifications:

- Add new method to PlatformDependent that can be used to check if default direct buffer usage was explicit disabled
- Use this method in our pooled ByteBufAllocator implementations to check if we should use direct buffers or not by default

Result:

Less memory copies and better performance when using the pooled allocators even if Unsafe can not be used.
@normanmaurer normanmaurer force-pushed the prefer_direct_buffers_pooled branch from 7c28748 to 25ca875 Compare May 22, 2025 16:31
@normanmaurer normanmaurer merged commit 7e96030 into 4.2 May 22, 2025
3 checks passed
@normanmaurer normanmaurer deleted the prefer_direct_buffers_pooled branch May 22, 2025 16:31
@normanmaurer
Copy link
Copy Markdown
Member Author

@chrisvest I think we also want this for 4.1, agree ?

@chrisvest
Copy link
Copy Markdown
Member

@chrisvest I think we also want this for 4.1, agree ?

Sure

normanmaurer added a commit that referenced this pull request May 22, 2025
#15232)

…sabled

Motivation:

We should always prefer direct buffers if the ByteBufAllocator
implementations are pooled as deallocating these buffers should be rare.

Modifications:

- Add new method to PlatformDependent that can be used to check if
default direct buffer usage was explicit disabled
- Use this method in our pooled ByteBufAllocator implementations to
check if we should use direct buffers or not by default

Result:

Less memory copies and better performance when using the pooled
allocators even if Unsafe can not be used.
normanmaurer added a commit that referenced this pull request May 23, 2025
#15245)

…… (#15232)

…sabled

Motivation:

We should always prefer direct buffers if the ByteBufAllocator
implementations are pooled as deallocating these buffers should be rare.

Modifications:

- Add new method to PlatformDependent that can be used to check if
default direct buffer usage was explicit disabled
- Use this method in our pooled ByteBufAllocator implementations to
check if we should use direct buffers or not by default

Result:

Less memory copies and better performance when using the pooled
allocators even if Unsafe can not be used.
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