[Mono-devel-list] malloc and free on CLI

[Ben Maurer]

On Sat, 2005-07-16 at 12:36 -0700, Jeyasankar Kottalam wrote:
> Hello,
> 
> I'm the student writing GCC-CIL for Mono as part of Google's Summer of Code.
> 
> How should I implement malloc and free on CLI? I've come up with a couple of
> ideas, but none of them seem particularly good to me:
> 
> - P/Invoke to native malloc and free
> 
>   Problem: The binary becomes tied to the details of the underlying platform to
> pull in a malloc from the appropriate library. Binary portability is lost.

Not really. Dllmaps could map from a "virtual" libc library to the real
libc. If you want to be especially clever and make the application run
on the msft runtime, the library name should be whatever the ms C
runtime is, since windows doesn't have dllmaps.

We already do this in Gtk#. One binary can run on MSFT's runtime and the
Linux runtime. Also, the data providers we have using p/invoke (eg,
sqlite) work on windows, linux and mac.


> Correct, but I am also writing a partial libc for a couple of
> reasons: 
> I'd like to be able to test "real world" applications, and it is also
> part of the acceptance criteria that I demonstrate a "real world" C
> application  under Mono.
> Regardless of whether I write the final implementation, this is an
> issue that needs to be considered.

Depending on the C libraries that the application depends on is likely
acceptable when running a real world app.

By mapping calls to external libraries to DllImport's we can do some
interesting things. Imagine compiling evolution and having it run with
mono. glib/gtk+ could still be native code to enhance performance.

That being said, an issue to think about: the user might want to compile
some of the libraries they depend on with the cil targeting gcc. For
example, say you are trying to compile the `svn' binary with gcc-cil.
You might also want to compile libsvn_* with gcc-cil, but not compile
libaprutil and libxml2 with gcc-cil and just depend on the native C
libraries.


> >Yes, I agree. However, I still need a mechanism to implement a heap.
> Even
> >if
> >porting an existing libc, that libc will need *some* mechanism to get
> >memory
> >from the runtime. What is the recommended way of doing that?
> 
> I think to get te better berformance you should implement heap
> functionality
> natively. But not using P/Invoke because it's inefficient. You should
> rater
> use InternalCalls. Use mono/mono/metadata/icall.c and
> [MethodImplAttribute
> (MethodImplOptions.InternalCall)].
> 
> This will result in a very good performance because there will be no
> marshaling. Note that however you should implement only necessary
> functionality in native code becasue it does not take advantage of
> JIT,
> optimizations and verifications. And you should not duplicate platform
> dependent or native code that can be implemented using managed code by
> calling Class Library functions.

Looking forward (in the medium-long term), the way icalls work is going
to need to change. For a precise GC to work, we'll need to know exactly
which calls hold gc references. icalls will probably need code to
interact with safepoints. So, it would seem that something like that is
prone to break.

Also, using icalls means that you must link with libmono.so, preventing
an application from running on the msft runtime.

-- Ben