[llvm-dev] A "Cross-Platform Runtime Library API" in LLVM IR

[David Chisnall via llvm-dev]

On 23 May 2016, at 10:13, Lorenzo Laneve <lore97drk at icloud.com> wrote:
> 
> I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster.

How?

> And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed.

On many *NIX platforms, libc or some equivalent is the canonical interface to the system.  

> I'm just assuming that the functions we use in C such as malloc() are quite high-level interfaces and that there might be something faster.
> 
> For example, does Swift use malloc() to allocate its objects?

A number of high-level language don’t use malloc, but not because it is too high-level; quite the reverse.  You can have a more efficient malloc implementation if you know something about allocation patterns.  For example, in a class-based OO language you’re likely to have a small number of class sizes and having a separate slab allocator for each of these can be faster.  If you need garbage collection, then you’ll want to associate more metadata with allocations.  

malloc() is about as low-level an interface to memory management as is possible while maintaining some abstraction: you give it a size (no type, for example) and it gives you a pointer to some uninitialised memory.  The only lower-level interfaces would be related to page table management (mmap and friends on *NIX, more complex APIs on Mach and entirely delegated page table manipulation on something like Xen or DUNE).

Again, what problem are you trying to solve?  What is your use case for such a library?

David