llvm dev - May 2016 - A "Cross-Platform Runtime Library API" in LLVM IR

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

I'm not talking about a new library instead of the libc, I'm talking
about letting people create a library optimized for a specific frontend,
regardless of the target.
> On May 23, 2016, at 1:06 PM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
>> 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
>

On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at icloud.com>
wrote:
> 
> I'm not talking about a new library instead of the libc, I'm
talking about letting people create a library optimized for a specific frontend,
regardless of the target.
It sounded as if you were talking about a library that sits underneath such a
thing.  Lots of languages have their own runtime libraries (I maintain two of
them), including Go, C++, Swift, and Objective-C.  These are generally intended
to be portable across front ends, defining the low-level binary interfaces that
compilers target.

David

On 23 May 2016 at 12:16, Lorenzo Laneve <lore97drk at icloud.com> wrote:
> I'm not talking about a new library instead of the libc, I'm
talking about
> letting people create a library optimized for a specific frontend,
> regardless of the target.
>
But HOW is that going to work for multiple languages, on multiple hardware
platforms. And have you got ANY evidence that the extra call level between
C++'s `operator new` and `malloc` actually causes noticeable overhead?

--
Mats
>
> > On May 23, 2016, at 1:06 PM, David Chisnall <David.Chisnall at
cl.cam.ac.uk>
> wrote:
> >
> >> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/abcaa1a0/attachment.html>