[Mono-dev] Does JIT produce code with frame pointer

Muath A. Khalaf moath2 at yahoo.com
Fri Mar 2 22:27:11 EST 2007

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:)


------------- OUTPUT ---------------------


samples  %        image name               symbol name


4099     42.2490    JIT.App                  recursive:Ack (int,int)

  4099     100.000  JIT.App                  recursive:Ack (int,int)


3145     32.4160    JIT.App                  recursive:Fib (double)

  3145     100.000  JIT.App                  recursive:Fib (double)


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                    

  2         9.0909      mono                    

  3        13.6364     mono                    

  16       72.7273    mono                    

22        0.2268       mono                     mono_metadata_decode_row

  22       100.000    mono                     mono_metadata_decode_row

----- 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
> 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.


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?


Want to start your own business?
Learn how on Yahoo! Small Business.
-------------- 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