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

[SR-7545] Swift should support using realloc for tail allocated classes #50087

Closed
weissi opened this issue Apr 26, 2018 · 12 comments
Closed

[SR-7545] Swift should support using realloc for tail allocated classes #50087

weissi opened this issue Apr 26, 2018 · 12 comments
Assignees
Labels
feature A feature request or implementation standard library Area: Standard library umbrella

Comments

@weissi
Copy link
Member

weissi commented Apr 26, 2018

Previous ID SR-7545
Radar rdar://problem/39761987
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee @weissi
Priority Medium

md5: 05a26fb36e0f13ceab8ad8129b713867

duplicates:

  • SR-6503 Support realloc() for tail allocated objects

Issue Description:

My last couple of days I spent on aggressively reducing the number of allocations we do in SwiftNIO for a simple echo server and mostly for the HTTP server. One of the most annoying things is that for every allocated ByteBuffer you will actually do two allocations:

1. the _Storage class itself for Cow (https://github.com/apple/swift-nio/blob/master/Sources/NIO/ByteBuffer-core.swift#L214)
2. the storage for the actual bytes (https://github.com/apple/swift-nio/blob/master/Sources/NIO/ByteBuffer-core.swift#L233)

It would be great to make use of Swift's tail allocated classes but then we couldn't do realloc anymore (which we currently do: https://github.com/apple/swift-nio/blob/master/Sources/NIO/ByteBuffer-core.swift#L258).

But really: we should support realloc ing tail allocated classes and we could shave another few allocations off.

@gottesmm
Copy link
Member

@swift-ci create

@belkadan
Copy link
Contributor

belkadan commented May 1, 2018

This is only possible if the class has exactly one strong reference and no weak or unowned references, and if all of the things stored in the class can be bitwise-copied. But that might be a workable and enforceable set of restrictions.

@atrick
Copy link
Member

atrick commented May 1, 2018

@belkadan I'm missing something. I would think you could theoretically realloc any (uniquely referenced) thing that is bitwise-movable. So, no ObjC weak/unowned refs, but everything else is ok.

@belkadan
Copy link
Contributor

belkadan commented May 1, 2018

IIRC we've gone back and forth over whether "uniquely referenced" includes weak and unowned refs (which it really should), but leaving that aside for the moment, isn't your list the same as mine?

@belkadan
Copy link
Contributor

belkadan commented May 1, 2018

Oh, "movable" instead of "copyable". Yes, you're right, I mistyped.

@atrick
Copy link
Member

atrick commented May 3, 2018

Can we make this a dup of https://bugs.swift.org/browse/SR-6503, or vice-versa.

@gottesmm
Copy link
Member

gottesmm commented May 3, 2018

SGTM

@weissi
Copy link
Member Author

weissi commented Nov 3, 2018

#19421

@weissi
Copy link
Member Author

weissi commented Nov 13, 2018

implemented

@belkadan
Copy link
Contributor

Should we have a separate bug for tracking getting it working on Darwin?

@weissi
Copy link
Member Author

weissi commented Nov 13, 2018

@weissi
Copy link
Member Author

weissi commented Nov 13, 2018

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added feature A feature request or implementation and removed bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. labels Jan 29, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A feature request or implementation standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

5 participants