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

[David Chisnall via llvm-dev]

On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote:
> 
> This is the point,

No, you are still failing to make a point.

> High-level OO languages don't use malloc(), they use something else.

That’s not entirely true.  They need to get the memory that they provide to programs from somewhere.  They may provide their own pool allocators, but they will often just call malloc() and then subdivide the returned chunk.  If they’re doing garbage collection, they will ask for a large number of pages and use that as a heap managed by the garbage collector.

> 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;
> }

You have still completely failed to explain why __alloc() is better than malloc().  If you wish to implement a language-specific allocator like this, then why would it want to call __alloc() from your hypothetical library instead of malloc(), provided by something like jemalloc(), which has over a decade of careful optimisation behind it to ensure that it scales well on multithreaded systems?

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

Again, why would I, as the author of a high-level language, want to depend on your runtime library?  You have not given a compelling use case for someone wanting to depend on your hypothetical runtime library instead of the target platform’s libc.  If I write my language-specific code against libc, then other people will implement the platform-specific parts for me.  I can rely on C interfaces existing on pretty much any platform that I want to target, from desktop and server operating systems down to real-time embedded operating systems.  What does your proposal give me?

David