[Mono-dev] Profiler extension
massi at ximian.com
Mon Jul 21 01:56:15 EDT 2008
On Sun, 2008-07-20 at 14:43 -0300, Rodrigo Kumpera wrote:
> 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.
True, but it would allow unknown blocks, both now (if I "forget" to
modify some call to pass the enum) and most important in the future,
when new calls to mono_code_manager_reserve will be added.
And it would make me add new function names for the "extended API (like
"mono_code_manager_reserve_with_id") instead of reusing the current
ones, "growing" the API.
That said, yes, this is doable and would be anyway better than
scattering lots of explicit calls to the profiler API everywhere.
> 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
Yes, I know... I am tempted to put "additional information" besides the
enum, like a MonoClass* or MonoMethod*, so one can have more detailed
information (like "IMT thunk for class X").
It would not be difficult, just a bit more work (quite honestly, the
"hardest" part of the work is just going through the thunk types one by
one and decide what info one can put there exactly, like "specific
trampoline for method X", or "general method trampoline"...).
The run time overhead would not be noticeable, so If we think it would
be nice to have this kind of info I can do it.
It smells a bit of overengineering, but it's hard for me to judge it.
> 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.
More information about the Mono-devel-list