[Mono-list] [embedding] "moving from mono_runtime_invoke() to mono_method_get_unmanaged_thunk()" or "how to call class method that takes and returns a string via thunks"

[Robert Jordan]

Hi Jonathan,

On 12.11.2015 14:34, Jonathan Mitchell wrote:
>
>> On 12 Nov 2015, at 13:11, Robert Jordan <robertj at gmx.net> wrote:
>>
>> On 12.11.2015 13:52, Jonathan Mitchell wrote:
>>>
>>>> On 12 Nov 2015, at 12:41, Julian Mayer <julian at corecode.at> wrote:
>>>>
>>>> i didn't list any specific crash, because i tried in a million different ways and got a different crash each time.
>>>>
>>>> i've solved this now. it seems, a unmanaged thunk takes a hidden additional parameter, MonoException ** which can't be NULL. of course this isn't documented anywhere.
>>>>
>>> This I feel is a real problem for the embedded API as it is.
>>> The above is documented in the source, but not in the header.
>>> Source comment documentation is fine for the source authors but it leaves consumers out in the cold.
>>> The long and the short of it is that you really need to have the Mono embedded source to hand at all times even if you don’t build you own Mono.
>>
>> In the past, the source code comments were picked up by some
>> $TOOL and then published under some $URL of mono-project.com
>> by a $PERSON (with $PERSON == Miguel, IIRC).
> Yep, seen those. And as you say, less than complete. Traditional headed documentation is hard to beat though.
>>
>> If you have questions about this API area, feel free to
>> ask on this list. I'll do my best to answer them, if I
>> can recall ;)
>
> Okay, here goes!
>
> I use mono_runtime_invoke for Obj-C property and method calls as per:
> https://github.com/ThesaurusSoftware/Dubrovnik/blob/329aa5551a393c1dc609185164e35e44ddb27ba0/Framework/XCode/Utility/DBInvoke.m
>
> I use a code generator to produce my embedded API binding code.
> I reckon that if I can generate mono_runtime_invoke access code I can figure out how to do the same with thunks.
>
> Currently I build a MonoMethodDesc *cache keyed by the method name to feed mono_runtime_invoke at the call site.
> That part of the code predates your thunking API.
> I presume that to use the thunks the best approach would be to build the thunk lazily, stash it in an instance var and then use as and when required?
>
> I know this question is like, how long is a piece of linguine , but what sort of performance improvement does thunking potentially provide?


You're supposed to use the thunks lazily because:

1) thunks are methods which must be generated and take some
    memory (and CPU cycles during the generation).
    I wouldn't advice to generate thunks for the whole mscorlib
    in advance. This also applies to mono_runtime_invoke.

2) while thunks are also cached, their cache "strategy" is less
    complex than mono_runtime_invoke's wrapper caching.
    The latter is caching by signature while the thunks
    are cached by type + signature.


On performance: about 10^3 speed-up on a micro benchmark
which invokes a simple method like this 100,000,000 times:

public static float Add(float a, float b)
{
         return a + b;
}

See attachment.

Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunkbench.tar.gz
Type: application/x-gzip
Size: 1491 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20151112/af4a15ed/attachment-0001.bin>