[Mono-dev] Mono profiler agent for jitted code

[Yeh, Jason]

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.

Jason

mono-devel-list-bounces at lists.ximian.com wrote:
> Hi,
> 
> 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.
> Specifically: 
> 
>         * 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.
> 
> Joe
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list