[Mono-devel-list] method recompilation - looking for feedback
lupus at ximian.com
Mon Feb 14 08:46:58 EST 2005
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 at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list