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

mats petersson via llvm-dev llvm-dev at lists.llvm.org
Mon May 23 04:18:36 PDT 2016

Your FIRST premise, that languages don't use `malloc` to allocate memory is
incorrect in the first place.

gnu libc++:

libcxx (LLVM's C++ library):

My Pascal compiler does essentially the same thing:


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

> 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/02275b39/attachment.html>

More information about the llvm-dev mailing list