Re: Tracing objC messages

[David Chisnall]

Hi Lucas,

On 27 May 2011, at 15:55, Lucas Schnorr wrote:

> I have been working with trace visualization for a while, and I always wanted
> to trace objective-c applications (and especially gnustep-based apps)
> to have a space-time view of what is going on during execution. By trace,
> in this case, I mean a set of timestamped events that register the messages
> sent to the objects (method calls) and the entry and exit of each method
> execution.

Sounds useful.

> There are several benefits on this, but the two I appreciate the most is to
> get an (possibly detailed) behavior overview of a program, and to see
> where the program spent more time (a sort of performance analysis).

Yes, definitely useful.

> Is anyone already tried to do this type of tracing within the gnustep project?

I haven't tried very hard...

> Is there any kind of support in the libobjc2 runtime to do this type of 
> tracing,
> with timestamped events?

No, and it's complicated by IMP caching (which GNUstep does manually and the 
compiler will try to do automatically when you use the non-fragile ABI).

This is a bit easier to do on OS X, because objc_msgSend() encapsulates both 
the entry to and exit from the method.  With GNU runtimes, messages sends are 
implemented as one call that returns the IMP and another that actually calls 
the method.  It's trivial to hook into the first call, but much harder to hook 
into the second.

That said, it would be a fairly trivial modification to clang to emit a call 
before and after each message send to profiling functions.  For example, I 
could make do something like turning:

[foo bar];

into something equivalent to:

objc_profile_msg_enter(foo, @selector(bar), __FILE__, __LINE__);
[foo bar];
objc_profile_msg_exit(foo, @selector(bar), __FILE__, __LINE__);

You could then record timestamps along with this into a format that something 
else could parse.  I'd be happy to make this modification if you could define 
some interfaces for the profiling.

There is already some profiling support in libobjc2, but it won't do quite what 
you want.  It is intended for implementing type feedback, and will record the 
method used to implement every message send at each call site so that we can 
determine whether it's worth caching the IMP and can do speculative inlining 
(e.g. if a message send always calls the same method, then we can try inlining 
it - we also do that statically for class messages).  

David

-- Sent from my Cray X1