[Mono-devel-list] method recompilation - looking for feedback

[Paolo Molaro]

On 02/13/05 Willibald Krenn wrote:
> Q: When is it allowed to move a method?
> A: In case every CEE_LDFTN / CEE_LDVIRTFTN was used to create a 
> delegate. In any other case, it's not safe to move a method.

I'm not sure what you mean, but if CEE_LDFTN or CEE_LDVIRTFTN
have been seen, it's not safe to remove a method's code, since the
resulting pointer could have been stored anywhere.

> Q: How to track delegates?
> A: This is a little bit more tricky. Basically it could be done in sync 
> with GC or by including some list in MonoJitInfo.. While the latter 
> still needs support for delegate-cloning (etc), the former needs 
> modifications to the GC. Any ideas which one would be easier/better?

For methods that can be dynamically recompiled or whose address is taken
with ldftn-like instructions, we need to keep the trampoline around
and patch it to jump to the new code.

> Q: How could raw IP -> MonoJitInfo ptr translation be more efficiently 
> made from within signal handler?

This has a surprising cost in exception handling, too (the profiler signal
handler should likely just store the ip and not do much processing).

> A: I thought of adding a pointer to the MonoJitInfo structure -ptr_size 
> bytes before the first opcode of the method. Within a signal handler it 
> should be quite easy to obtain the starting address of the current 
> method as bp-1 points to after the method call opcode and e.g. on amd64 
> one opcode before r11 gets loaded with the call target...

This is not a solution: the amd64 call sequence needs to be changed to
not do that, since it's too slow (and you wouldn't handle virtual calls
that way etc).
For a number of reasons, the jit info lookup should also become
lock-free, so ideas and patches to make this function faster are welcome.

> Q: How to interface with C# code?
> A: I thought about adding some new class in a custom Mono namespace that 
>  returns a wrapper around the MonoJitInfo structure. (Read only of 
> course and probably without the information about the code location, but 
> with information about optimizations, weight, recompile-times, probably 
> other profiler data..)

I don't see the need to expose MonoJitInfo to C# code, we're also not
going to make that structure larger: it needs to remain light-weight
for the default case (it will actually be shrinked).

lupus

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