<div dir="ltr"><div><div>Your FIRST premise, that languages don't use `malloc` to allocate memory is incorrect in the first place.<br><br>gnu libc++:<br><a href="https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/new_op.cc">https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/new_op.cc</a><br><br></div><div>libcxx (LLVM's C++ library):<br><a href="https://github.com/llvm-mirror/libcxx/blob/master/src/new.cpp#L50">https://github.com/llvm-mirror/libcxx/blob/master/src/new.cpp#L50</a><br></div><div><br></div>My Pascal compiler does essentially the same thing:<br><a href="https://github.com/Leporacanthicus/lacsap/blob/master/runtime/alloc.c">https://github.com/Leporacanthicus/lacsap/blob/master/runtime/alloc.c</a><br><br>--<br></div><div>Mats<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 May 2016 at 12:00, Lorenzo Laneve <span dir="ltr"><<a href="mailto:lore97drk@icloud.com" target="_blank">lore97drk@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is the point,<br>
High-level OO languages don't use malloc(), they use something else.<br>
My idea was a C API with implementations of functions:<br>
For example<br>
Assuming I need to implement a function which allocates a new object.<br>
The API provides a really basic allocator function I can use to implement the complete function the high-level language needs.<br>
<br>
void *__newobject(int class_size) {<br>
 void *r = __alloc(class_size);<br>
 // Add GC metadata here<br>
 return r;<br>
}<br>
<br>
This function will be included in the runtime library. Obviously this is a stupid example maybe a better implementation can be done.<br>
<br>
Something like this can be done for I/O.<br>
<div class="HOEnZb"><div class="h5"><br>
> On May 23, 2016, at 11:28 AM, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
><br>
>> On 23 May 2016, at 10:13, Lorenzo Laneve <<a href="mailto:lore97drk@icloud.com">lore97drk@icloud.com</a>> wrote:<br>
>><br>
>> I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster.<br>
><br>
> How?<br>
><br>
>> 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.<br>
><br>
> On many *NIX platforms, libc or some equivalent is the canonical interface to the system.<br>
><br>
>> 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.<br>
>><br>
>> For example, does Swift use malloc() to allocate its objects?<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> Again, what problem are you trying to solve?  What is your use case for such a library?<br>
><br>
> David<br>
><br>
</div></div></blockquote></div><br></div>