Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a
change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at
This proposal is being run by the Platform Steering Group, not the Language Steering Group. You are right that this proposal does not have implications on the language itself.
Just as a process note for review managing, I recommend merging the swift-evolution PR and linking directly to the markdown document in the review thread.
Looks fairly low risk, and if it gives a measurable performance benefit I say go for it.
Has the performance impact of alternative allocators been measured on Linux and macOS, to see if switching to something else on those platforms could be fruitful?
This is correct, this is the memory allocator for the compiler, the runtime will continue to use the system allocator. If there is value and interest in changing the memory allocator for the runtime, that should/would be a completely different proposal.
I also object to this going through the evolution process. It’s reasonable for changes to the compiler to go through broad review sometimes, e.g. new command-line arguments, coming up with a platform support policy, and of course changes that would affect the output. But from reading the proposal, this is none of those, this is just an implementation decision.
If it’s that important to gather feedback on, then sure, it could get a forum-wide announcement. It could even have a designated review period. But it should not be in the Evolution category, and it should not use the same SE numbering system, and it should not be jammed into a proposal format that doesn’t match the change being proposed.
That's not really an option. mimalloc is released under the Expat license, which is incompatible with the LLVM license.
It is questionable whether it works for the compiler. It's not questionable that it would absolutely not work with the runtime, unless an explicit license is obtained from Microsoft and/or the mimalloc dev team..
The "MIT license" is, at best, a colloquial name for both the Expat license and the X11 license. At worst, it's a name for every license used by MIT to release software, of which there are many.
Huh? A cursory look around the internet shows that bundling works licensed under the MIT license—a very specific text, not "every license used by MIT"—or similar licenses into works licensed under the Apache 2.0 license is certainly permitted.
Case in point: LLVM itself (licensed under Apache 2.0 with LLVM exceptions, which make the license more permissive) includes legacy contributions which haven't been relicensed that are governed by the MIT/BSD-like UoI-NCSA license.
Anyway, this isn't a lawyer forum; the review is about the technical merits of the proposal.
While it's legitimate to raise a concern that there might be licensing issues, can we please avoid making statements in the forums that might be construed by others as legal advice?
On this front it's also worth remembering that both the Swift and LLVM projects have access to qualified legal experts, who can — and will — have the final say on licensing and are able if necessary to negotiate suitable terms with other parties on our behalf.
We won't be switching on macOS. Linux maybe (though not as part of this proposal), but macOS definitely not. If there's some way the system allocator on macOS could be improved, we know the people to talk to about that
One could fairly easy imagine a world where mimalloc would be a strict improvement over the current macOS allocator and evaluating it as a drop-in replacement might be considered instead... (disregarding legals and NIH aspects of course).
Just saying
But that's off-topic (on a sidenote, we have it on our to-do list to evaluate mimalloc on Ubuntu for the runtime performance, but that's some way off still).
Seems fine to me—not even sure this needed a proposal, to be honest, as it seems like a pure implementation detail with no[1] externally observable effects.
There are always observable effects, but… you know what I mean. ↩︎
@compnerd One thing that did just spring to mind while thinking about the kinds of things that replacing the allocator might disrupt is swift-inspect. The compiler has an increasing amount of Swift code in it, and since swift-inspect works by iterating the heap, I wondered whether you'd given any thought to the effect that using mimalloc might have there?
I think that this should be something that is possible to accommodate. As we are currently adding support for Linux and Android to swift-inspect, there are two things of note:
swift-inspect largely doesn't care about the heap iteration (except for array analysis)
It is possible to deal with other memory allocators (we already deal with bionic, glibc, musl, and ucrt). The worst case scenario is that we may need to introduce a flag to select between memory allocators as there is no standard interface to query the heap allocations.
An interesting scenario to consider: users are permitted to hook/replace malloc, free, operator new, operator delete. This is something that swift-inspect needs to deal with irrespective of what we are doing here.
The fact that Swift respects operator new overrides is a mistake, IMO. The Objective-C runtime made the same mistake for far too long, and eventually had to switch to calling the allocator directly. (I’m not sure it even supports malloc overrides anymore; @al45tair would know.)
I consider it inevitable that Swift will eventually follow in Objective-C’s footsteps and bypass the override able C++ allocator functions.
Edit: @Joe_Groff tells me this might have already been done. Again I defer to Alistair and @Mike_Ash.
