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 <[EMAIL PROTECTED]> 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@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list