[Mono-dev] Profiler extension

[Zoltan Varga]

Hi,

  I think the best approach would be to add a method to the internal
profile api to
register these functions, instead of making the code manager in mono/utils
depend on the profiler in mono/metadata. Also, instead of using an enum
(adding another dependency between metadata and the jit), it is much easier to
use a string like:
mono_profiler_register_anon_code ("generic_trampoline_0", code, code_size)

this makes printing out the info easier too.

                   Zoltan

On Mon, Jul 21, 2008 at 7:56 AM, Massimiliano Mantione <massi at ximian.com> wrote:
>
> 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
>> path.
>
> 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.
>
> Also true.
>
>> 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.
>
> /me too
>
> Ciao,
>  Massi
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>