Re: Profiling Traces

[David Chisnall]

Hi Ivan,

TESLA has a web site, which covers getting started:

http://www.cl.cam.ac.uk/research/security/ctsrd/tesla/build.html

For the traces, I actually replaced the debugging printf handler to log the raw 
events.  We're hopefully going to separate TESLA into some cleaner layering, so 
the event-generation code is more isolated from the event-handling code and we 
can more easily plug other bits of tracing into it.  

If you just want traces of message sends, then the latest version of the 
runtime has a mechanism for interposing on a particular selector, which is what 
TESLA uses.

David

On 23 Dec 2013, at 15:49, Ivan Vučica <address@hidden> wrote:

> Thread necromancy!
> 
> During GSoC2013, I would have loved to have something like the contents of 
> "Drawing.log", annotated with screenshots and perhaps some additional state 
> etc. As you mentioned, it would have helped a lot in development of the Opal 
> backend.
> 
> Is something like generating screenshots (or making a function call), then 
> integrating an <img src=""> inside the log, possible with TESLA?
> 
> Any instructions on using TESLA?
> 
> On Wed Oct 02 2013 at 3:59:25 PM, David Chisnall <address@hidden> wrote:
> Hello all of the GNUstep developers,
> 
> We've recently been working on a tool called TESLA that allows you to write 
> temporal assertions (e.g. before you get here, this other function must have 
> been called and returned this value) that are checked at run time, but also 
> provides a convenient way of adding instrumentation to programs.
> 
> I've uploaded a couple of profiling traces to give people an idea of the 
> kinds of thing this can generate:
> 
> http://theravensnest.org/Drawing.log
> http://theravensnest.org/NSCursor.log
> 
> The first is a log of all of the drawing messages in the protocol defined by 
> NSGraphicsContext (i.e. the thing used to communicate between -gui and 
> -back), indented based on the current view and cell that is responsible for 
> the drawing.  This doesn't provide a full stack trace, just some context.  
> The motivation for this is Ivan's work on the Opal back end, and looking at 
> exactly how the back end is used.  Are we doing too many pushes and pops of 
> graphics state, or saving and restoring when we don't need to?  Are we 
> calling methods a lot that are poorly optimised in the back end?
> 
> The second is a stack trace, generated in every place where we call a push or 
> pop method.  The motivation for this was the recent work trying to find bugs 
> in the NSCursor balancing code.  Unfortunately, I wasn't able to reproduce 
> the bugs when I tried (maybe they're all fixed?) and so this isn't very 
> useful, although it might be interesting.
> 
> Can anyone else think of other useful traces that we might want to generate?
> 
> David
> 
> -- Sent from my Apple II
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


-- Sent from my Cray X1