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

[Kornél Pál]

>From: Jeyasankar Kottalam

>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.

>I only referenced C# as a possible candidate to implement the malloc() and
>free() in because it's easy to interface with the Mono Class Libraries
>using
>C#. Then we could use whatever mechanisms are available in the Mono Class
>Libraries to implement the heap. Otherwise I would need to implement the
>mechanism to interface with CLI classes from C/C++ before I could even have
>a
>functioning heap.

OK, now I'm understand that your implementation does not have metadata
(primary classes and methods) import and reference features from other
assemblies yet. I think a managed libc should use Class Library where
possible instead of reimplementing everything like MS does. And this
requires OOP functionality. So you should use C# but should not spend too
much time to implement a libc in C#.

>When I have the time, I'll look into porting one of the small libc
>implementations (e.g. newlib, uclibc) to Mono.

But I think they should be ported to managed C instead of C#.

>> So I think your implementation should not require libc and should link
>> libc
>> as a managed assembly using metadata references to be platform
>> independent.
>If by "not require libc" you mean "not require the native libc", that's
>what I
>have in mind. Otherwise I would have used P/Invoke to make calls to the
>native
>library. (and the heap problem would be a non-issue)

I mean that MS VC++ cannot compile assembiles without libc (msvcrt
actually). In VC++ 2005 Beta 2 it is possible to compile applications
without CRT with some hacks (adding a function named ".cctor", very strange
but required) but in earlier versions it's completly impossible.

So the compiler should not relay on libc it should use it just like a
referenced assembly to resolve libc functions. Sometime it's good to use the
language C++ but use the Class Library instead of libc. For example Visual
Basic .NET has a huge runtime library and MS vbc.exe emits a lot of runtime
calls even when you do not use any runtime functions.

So I mean that the emitted code should be libc independent and only
referenced libc functions should use libc.

Kornél