[Mono-dev] Profiler extension

[Rodrigo Kumpera]

On Sun, Jul 20, 2008 at 11:59 AM, Massimiliano Mantione <massi at ximian.com>
wrote:

>
> Hello!
>
> Rodrigo and others were asking to extend the stat profiler to recognize
> also trampolines and thunks (right now they show up as "unknown").
>
> I have looked at the code, and found that the different categories of
> "thunks" we have are, roughly:
>
> - create_fnptr
> - load_aot_method
> - imt thunk
> - jump table
> - debugger code
> - exception call filter
> - trampoline (various types)
> - throw corlib exception
> - restore context
> - throw exception by name
> - handle stack overflow
> - throw exception
> - delegate invoke implementation
> - cpuid code :-)
>
> There are more than 70 places in the code that reserve memory from a
> code manager to produce those small code snippets that we'd like to
> track.
>
> Typically, when we add profiling infrastructure, we do not change the
> runtime API, we just insert calls to the profiler APIs in the relevant
> places.
> However, in this case I'd really, really prefer to:
> - create an enum with all the "thunk categories" above,
> - add it as a parameter to "mono_code_manager_reserve*" functions, and
> - call the new profiler API from there.
> This will make the code more compact (without those 70+ calls to
> profiler APIs scattered around), will make sure I don't miss any spot,
> and (most important) will make sure that future code maintenance will
> not forget to call the profiler API as well.
>
> But before doing that I wanted to know if changing the code manager API
> was OK...
>
> Ciao,
>  Massi
>


You can change the codeman API in non breaking ways, if necessary. By making
the
current allocation function tell the profiler that these are unknown blocks.
I like  this solution
as it would make changes more incremental.

Using an enum to encode the kind of thunk has the advantage of been easier
to encode in
a more compressed way, but reduces the report precision of what is been hit.
For instance, it
would make harder to detect if we have long IMT thunks on a hot code path.
On the other
hand, a lot of information can be extracted from call chains and it might be
just enough.

I believe that using an enum is enough for all use cases I have, as the
other information I can
derive from call chain. I would be nice to hear from others about this
subject, thou.



Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080720/ca754e9f/attachment.html