Make libcore friendlier to heap users

1

ATM libcore is designed with zero heap usage in mind. While it’s a good decision overall, it doesn’t take into account cases when you want to work with constrained environment but actually use heap. And, as the other side of the coin, we have no types in libcore/libstd which would ease life of people who interact with C libs with their own allocation interface. Which is a common practice, especially on Windows, due to runtime hell.

TL;DR:

  1. Move std::heap::Alloc trait from libstd to libcore and reexport it in former, like we do with many other types. Please note this doesn’t imply implementing it in libcore - just have common abstraction always at hand.
  2. Add lowlevel container types to libcore which explicitly require allocator to be passed to them and don’t fail:
  • CoreBox<T, A: Alloc> which behaves just like normal box, but is typed with allocator type, requires its instance to be passed in and returns allocation error instead panicking on allocation failure
  • CoreDynArray<T, A: Alloc> - behaves similar to Vec, but goes fallible allocation route and requires explicit allocator, just like CoreBox. Availability of stuff like try_reallocate is yet to be decided.

The actual design is of course up to discussion. Here I want to discuss general idea.

5 Likes
2

Why does putting this in libcore matter? Wouldn’t you pull in liballoc in these cases, and use them from there?

1 Like
3

liballoc AFAIK pulls in its own implementation. My idea was to have some useful building blocks in libcore without actually depending on concrete allocator.

4

liballoc does not pull in a concrete allocator implementation. That comes from liballoc_system and liballoc_jemalloc.

5

liballoc does something similar, it defines alloc::heap::Heap, so it depends on heap allocation.

6

That requires that there’s a #[global_allocator] somewhere, but it doesn’t care what it is. I know there was discussion of moving Alloc to core, but I can’t remember what the status was. I know some people wanted core to avoid any hint of dynamic allocation.

7

liballoc comes with a ton of heap-using types, in fact most, if not all, heap-aware types in libstd. I’m talking about ability for someone to not depend on global heap, but have access to Alloc trait itself and some basic tools atop it.

8

The fact that libcore comes with no heap use guarantee is very nice and I think it should be kept (or we’ll need a new lint). liballoc used to not pull any of the libcontainers types, but now it does. I believe the libs team decided that it should. If something, you should make an argument that this decision should be reversed.

9

I’d prefer if Alloc could be closer to the root and the things built upon it in a different place.

Ideally, Vec would be Alloc-generic and it could be place in a lower layer than heap allocation.

Dependency tree, which is really just spitballed:

  • Alloc trait
    • Simple collections (Vec)
    • Heap allocation
      • “Infallible allocation”?
        • Complex collections (BTreeMap)
1 Like
10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.