[Mono-dev] Does JIT produce code with frame pointer
Muath A. Khalaf
moath2 at yahoo.com
Fri Mar 2 22:27:11 EST 2007
Hi,
For OProfile I am just implementing part of the project as a graduate
course project. I am implementing the memory map from mono JIT
to OProfile. How OProfile handles this data and match it with the
anonymous methods it has, is implemented by someone else in the Lab
and still not complete yet. Now we are able to get reports about mono
apps using opreport and it will give us each method sampled with its fully
qualified name. The problem is with callgraphs. OProfile gave us the call
graphs for mono itself (runtime, GC) but always gives us the name of the
managed methods isolated i.e. alone. Here is a sample form the output
for a recursive mono benchmark. As you can see we have a problem
when it comes to JIT.App which is the managed code.
But the mono methods are well. So this looks like as if Ack, Fib and
Tak are running separately in different stacks and also isolated from the
mono runtime itself. Otherwise we should have at least seen Main
method as it calls each one of them respectively. May be the problem is
related to our OProfile patch but I just wanted to avoid any surprises:)
Thanks.
------------- OUTPUT ---------------------
samples % image name symbol name
-------------------------------------------------------------------------------
4099 42.2490 JIT.App recursive:Ack (int,int)
4099 100.000 JIT.App recursive:Ack (int,int)
[self]
-------------------------------------------------------------------------------
3145 32.4160 JIT.App recursive:Fib (double)
3145 100.000 JIT.App recursive:Fib (double)
[self]
-------------------------------------------------------------------------------
2373 24.4589 JIT.App recursive:Tak (int,int,int)
2373 100.000 JIT.App recursive:Tak
(int,int,int) [self]
-------------------------------------------------------------------------------
1 4.5455 mono
mono_get_method_from_token
2 9.0909 mono
mono_metadata_get_param_attrs
3 13.6364 mono
mono_metadata_load_generic_params
16 72.7273 mono
mono_metadata_get_generic_param_row
22 0.2268 mono mono_metadata_decode_row
22 100.000 mono mono_metadata_decode_row
[self]
.
.
.
.
----- Original Message ----
From: Massimiliano Mantione <massi at ximian.com>
To: Muath A. Khalaf <moath2 at yahoo.com>
Cc: mono-devel-list at lists.ximian.com
Sent: Thursday, March 1, 2007 11:24:54 PM
Subject: Re: [Mono-dev] Does JIT produce code with frame pointer
On Thu, 2007-03-01 at 21:21 -0800, Muath A. Khalaf wrote:
> 1- I want to ask if JIT produces code that has a frame pointer i.e.
> something similar to what you get when you omit the
"-fomit-frame-pointer"
> option with gcc.
Yes, we use the frame pointer.
> 2- Is it correct that: a mono single threaded program has only two
> runtime
> stacks one for the application thread and the other for the GC thread.
> This
> means that when a managed method calls an internal mono method (icall)
> then
> on the app runtime stack I will have the managed method frame along
> with the
> icall frame on top of it (or below) of course with the wrapper in
> between.
There can be a finalizer thread, too (if it's not disabled).
> This is important as I am trying to integrate OProfile with mono and
> want
> to understand the stacks that should be sampled by OProfile to test
> them.
Interesting!
But why should OProfile ignore the gc and finaliser stacks-threads?
IMHO, one of the great things of OProfile is that it's a system-level
profiler, which samples everything... what if in my application those
threads play an important role performance-wise?
Of course it's possible I'm missing something...
However, I had the impression that the only thing that OProfile needs to
know is the mapping from memory regions to methods in the source code.
BTW, are you basing your work on the OProfile/Java integration done
by IBM, or are you restarting from scratch?
Ciao,
Massi
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070302/2c4f89eb/attachment.html
More information about the Mono-devel-list
mailing list