4 ms·
Yes, there is progress. But it is very far from anything you might consider complete or arguably even usable--there's no implementation of malloc or basic stdio
by jcranmer 5y ago
Yes, there is progress. But it is very far from anything you might consider complete or arguably even usable--there's no implementation of malloc or basic stdio, for example.
- cclearwater 5y agoWouldn't they just use Google's tcmalloc?
- fyrn- 5y agoProbably not the ideal pick for an everuone facing library like this, tcmalloc focuses on reducing core thread contention, at the cost of compactness and often debugability. I've not been following the ptoject for some time though, so maybe things have changed. Still a great allocator if those tradoffs are what you want. Something more like mimalloc would probably be a better general purpose allocator for something like this
- dxf 5y agoThe plan is to use Scudo, which is the allocator that lives in compiler-rt. Edited to include the link to Scudo: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/scudo https://github.com/llvm/llvm-project/tree/main/compiler-rt/l...
- dxf 5y agoEdited again: I am reminded that you can already get scudo today by using a CMake option to include scudo when building LLVM-libc.
- scrb 5y agoUsers wanting allocator functions (malloc and friends) from LLVM libc will get the SCUDO allocator. They need to use a special CMake option to include SCUDO when building LLVM libc.
- dogleash 5y agoHas there been any refinement on a mission statement for it? If I recall correctly from the mailing list when this was first proposed, someone had a use case for custom libc but extending it to a general purpose libc diminished properties that would distinguish it from (e.g.) musl-libc.