[Mono-dev] Mono profiler agent for jitted code
bmaurer at ximian.com
Fri Mar 31 12:56:34 EST 2006
I'm glad to see interest in this again. I took a quick look at this during
a week I was in Boston over my winter break. I checked some code in to svn
to emit a ELF file in (what I think is) the correct format for oprofile as
it works right now.
I know the state of anonymous samples for oprofile is in quite a state of
flux. Once a proposal and implementation is in place for oprofile, we have
a team of people whom I'm sure we can get to have a working mono agent
(Paolo, Massi, Zoltan, and myself should all be up to the task, time
If you need help navigating the Mono code base, please feel free to ask on
this list, or join us on IRC.
> This is rather off topic from the original thread "What would you like
> to see in Mono". Thus, I created a new thread for this discussion while
> leaving Joe's original message in this mail.
> I have been working on a proposal to extend Oprofile to profile the
> "anonymous samples" resulted from jitted code. I am not familiar enough
> with Mono to determine how such profiler will benefit Mono. I would
> like to know if such profiler would benefit Mono, and also how would you
> use this profiler if it is available.
> If this profiler can benefit Mono, I would like to write a profile agent
> for Mono and make sure that it will work with Mono. It would also be
> great if someone can point me the files that I should check if I ever
> need to look at how Mono creates jit code.
> mono-devel-list-bounces at lists.ximian.com wrote:
>> This stretched out a bit more than I originally intended. :)
>> On Tue, 2006-03-28 at 20:47 -0500, Miguel de Icaza wrote:
>>> What would be the top feature you would like to see in Mono?
>> Although not really in Mono itself, one thing I would like to
>> see is better integration with automake. The main Beagle
>> Makefile.am is currently 1181 lines. There is definitely
>> room for us to clean this up substantially a bit on our own,
>> but I've love to see things like compilation handled
>> automatically, installation of .mdb files, maybe even
>> automatic gacutil for assemblies, etc.
>> Beyond that, additional profiling tools would help a lot.
>> * A profiler that tracked threads.
>> * A profiler that tracked when files were opened and closed.
>> * A profiler which detected potential deadlocks.
>> I'd recommend really investigating all the profilers and
>> debugging tools available for Java and then work on
>> implementing them in Mono. As I've said to you personally
>> many times before, the biggest difficulty in developing
>> applications in Mono at this point is a lack of high-quality tools.
>> In addition, various bug fixes related to profiling:
>> heap-buddy locks up instantaneously on SMP machines (not sure
>> if Jon ever filed that or had just had discussions about it
>> with Ben and others) and more robust reporting of the stack
>> traces of all threads with SIGQUIT.
>> It might also be helpful if the various profilers could be
>> integrated into MonoDevelop or something to give profiling
>> info while the program is running. This data is most useful
>> when it can be visualized.
>> Coverage tools, both at compile and runtime, integrated into
>> Mono would be handy. I am sure .NET ones exist out there,
>> but they're neither immediately obvious nor immediately
>> useful inside a Unix Mono development environment.
>> And one thing that has always bugged me: my apps all behave
>> strangely and then crash when I recompile underneath a
>> running instance. That's very annoying, and I suspect it's
>> also a problem if you upgrade packages and an app is running as well.
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list