Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

byte-buffer: use malloc_good_size on Darwin to allocate memory #3066

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

natikgadzhi
Copy link
Contributor

Motivation:

With this change, on Darwin, ByteBuffer will use less memory, and memory allocations will be aligned with pages better, hopefully improving memory efficiency.

This is part 1 of #2770. The next step is to figure out better allocation strategy for Libc, Musl, etc.

Modifications:

  • Introduces a new internal helper method to _Storage that returns the optimal storage size
  • Uses that to malloc capacity.
  • A few tests to verify allocation sizes.

Motivation:

With this change, on Darwin, ByteBuffer will use less memory, and memory
allocations will be aligned with pages better, hopefully improving memory efficiency.

Modifications:

- Introduces a new internal helper method to `_Storage` that returns the optimal storage size
- Uses that to malloc capacity.
Copy link
Contributor

@Lukasa Lukasa left a comment

Choose a reason for hiding this comment

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

Mostly great, one quick note!


@testable import NIOCore

#if canImport(Darwin)
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's make these tests cross-platform by redefining the logic here. We can just have an abstraction function that is essentially equivalent to mallocSize, but allows us to validate that that's what we're actually using.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Lukasa apologies for the delay — I think this gets it to a good spot. Once that gets in, I'll get a bit more experience around ByteBuffer and then see if it's useful to figure out better Linux allocation strategies.

@natikgadzhi natikgadzhi requested a review from Lukasa January 26, 2025 19:42
@Lukasa Lukasa added the 🔨 semver/patch No public API change. label Jan 27, 2025
func testZeroCapacity() {
let allocator = ByteBufferAllocator()
let buffer = allocator.buffer(capacity: 0)
XCTAssertEqual(buffer.capacity, 0)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we asking for capacity differently here than in the rest of the tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same approach as the rest of the tests would be fine, BUT zero being explicit feels nice.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it might be nice to keep the tests discussing capacity the same way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants