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

Willibald Krenn Willibald.Krenn at gmx.at
Sun Feb 13 11:41:28 EST 2005


As recompilation of methods without freeing the old image is just half 
the fun, I'm looking for comments on a few of my thoughts on how to move 
a method and update all delegates..

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.
Could be implemented as a counter in MonoJitInfo, is this correct?

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?

Q: When to free an old method code block
A: If no thread is active in the code block,
if all delegates have been updated and the VMT patched.
In case of instance methods ('not virtual'), things get
a little bit more complicated: Probably some trampoline code has to
be installed that jumps to some internal method which patches the
caller code.

Q: Re-Use MonoJitInfo structure on recompilation or allocate a new one?
A: I tend to prefer re-using of the structure... In this case, however, 
we would need some other queue that contains information about methods 
to replace (and the status of the replace/move operation..)

Q: How could raw IP -> MonoJitInfo ptr translation be more efficiently 
made from within signal handler?
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...
In case of a sampling profiler this would save lots of calls to the 
binary search algo that translates the raw IP into the MonoJitInfo pointer..

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..)

Thanks for feedback,

More information about the Mono-devel-list mailing list