[Mono-dev] (Delegate) Trampoline executed twice?
Rodrigo Kumpera
kumpera at gmail.com
Wed Dec 8 20:56:56 EST 2010
On Tue, Dec 7, 2010 at 10:13 AM, Martin Däumler <mdae at cs.tu-chemnitz.de>wrote:
> On 07.12.10 10:54, Robert Jordan wrote:
> > On 07.12.2010 08:52, Martin Däumler wrote:
> >>
> >> I expected a delegate trampoline to be executed only once
> >> like "common" JIT trampolines for a single call instruction.
> >> However, it might be executed twice.
> >
> > It could be related to the fact that the code behind
> > Thread.Start () is eventually calling delegate's Invoke
> > method via mono_runtime_invoke ().
>
> Hello,
>
> thank you for the answer. As you say, the delegate trampoline is
> called a second time through mono_runtime_invoke(). So I want to
> know if there might be other trampoline types that might be
> called a second time.
>
> A simple JIT trampoline patches the callsite so it is not possible
> that this JIT trampoline is called from that memory address. But
> obviously, this does not hold for delegate trampolines.
>
> So, I want to know, if there are other trampoline types that might
> be called a second time in that way?
Quite a few trampolines are not patchable.
Direct method delegates trampolines have a per callsite
cache of the target method to speedup the trampoline invocation
with is per-instance (eg, only the first call takes the tram).
Virtual method delegates are only done one per instance but don't
feature the per callsite cache for obvious reasons.
The generic sharing context fetch trampolines can't be patched out
since they are context dependant.
Class init trampolines are not, in some generic corner cases, patchable
using the rgctx fetch machinery.
Monitor enter/exit and generic virtual remoting are also obviously not
patchable.
The only case of patchable trampolines that we miss is indeed for direct
method delegates.
It is somewhat easy to implement such thing if you desire.
Virtual method delegates creation/first invocation could be speedup if one
wanted to spend time
on it.
There are other parts of the runtime that require proper warm up/AOT for
what you want: IMT slots,
virtual generic methods and variant type dispatch slots.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101208/e9dce53c/attachment.html
More information about the Mono-devel-list
mailing list