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