[Mono-dev] embedded runtime questions

[Paolo Molaro]

On 09/09/05 Allan Hsu wrote:
> Now, on to some questions I have regarding the Mono embedded C API:
> 
> 1. Under the Mono 1.1.8.1, (most recent release made for OS X), the  
> instructions from the Wiki entry  (http://mono-project.com/ 
> Embedding_Mono#Threading_issues) to call mono_thread_attach don't  
> work in all situations. I get an error telling me to include <gc.h>  
> before <pthread.h>, which is impossible for me to do in the cases  
> where the current thread was not created by my own code.

Upgrade to 1.1.9, this issue should be fixed (at least as long as you
call mono_thread_attach()).

> Instead, I've been using mono_thread_create in an Objective-C  
> NSThread poser class. Is it safe to do this? This function is not  
> mentioned in the Wiki entry. If so, is there any additional setup/ 
> teardown I need to perform? It seems to work, but I'm unsure as to  
> whether or not I'm being totally clean about it.

It's not fine as the thread stack is not registered with the GC so some
objects could be freed under your back. Upgrading to 1.1.9 should not
require this hack.

> 2. Is there a facility to get a MonoMethod* that is more specific  
> than mono_class_get_method_from_name? This works fine until you have  
> multiple methods with the same name and the same number of arguments.  

See the other reply on the list, or the sample programs in
mono/samples/embed (test-invoke.c for example).

> 3. Is there any way to reduce method invocation overhead past caching  
> MonoMethod*s? I notice that mono_jit_runtime_invoke in mini.c emits  
> and compiles an invocation wrapper with this function prototype:
> 
> MonoObject *(*runtime_invoke) (MonoObject *this, void **params,  
> MonoObject **exc, void* compiled_method);
> 
> As far as I can tell, every time mono_jit_runtime_invoke is called,  
> it has to make sure that the MonoMethod in question is inflated and  
> JITed and that it there is also an invocation wrapper emitted and  
> JITed before actually calling the runtime_invoke function. I would  

Some of the complexity is because that function is also very flexible.
We may provide an API like the following:
	typedef void* MonoInvokeHandle;

	MonoInvokeHandle mono_runtime_prepare_invoke (MonoMethod *method);
	MonoObject*      mono_runtime_invoke_handle  (void *obj, void **params, MonoObject **exc, MonoInvokeHandle method_handle);

You can easily prototype that, and test to see how much of a speedup it is.
My plan is to eventually do it with a different invoke interface,
though, because in my tests the biggest overhead with the current
interface is that we need to allocate an object if the method returns a
valuetype: I'd like to fix both performance issues at once.

> Even better would be if it were possible to JIT the invocation  
> wrapper in such a way that saving a pointer to the compiled method  
> were not necessary.

We share the code for the wrapper method between methods with the same
signature, so this would require some additional complexity and memory
usage that I don't think is necessary with the above changes.

> Here are some of my informal benchmarking numbers on function calling/ 
> message passing/method invocation overhead on a 2Ghz G5 iMac. The  
> numbers are average call times for nop methods called several hundred  
> thousand times:
> 
> Objective-C message passing: ~.055 usec
> C# method calls: ~0.04 usec
> Full, non-cached embedded Mono C API lookup/invocation (parent  
> lookup, etc): ~6 usec
> locally saved Mono C API (using the same MonoMethod* over and over):  
> ~2.9 usec
> self-written caching, using Judy Arrays: ~3.2 usec
> 
> I'm currently using a caching scheme that uses (MonoClass*, method  
> name, number of arguments) as a key that maps to MonoMethod*  

The lookup is going to be your bottleneck with the above interface:
why do you need to poerform it at every call?

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better