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

[Lorenzo Laneve via llvm-dev]

This is the point,
High-level OO languages don't use malloc(), they use something else.
My idea was a C API with implementations of functions:
For example
Assuming I need to implement a function which allocates a new object.
The API provides a really basic allocator function I can use to implement the complete function the high-level language needs.

void *__newobject(int class_size) {
 void *r = __alloc(class_size);
 // Add GC metadata here
 return r;
}

This function will be included in the runtime library. Obviously this is a stupid example maybe a better implementation can be done.

Something like this can be done for I/O.

> On May 23, 2016, at 11:28 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
>> 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
>