[ANN] The Jejak Trace framework

> I announce the first availability of the Jejak trace framework at
>
> http://ss3.gemstone.com/ss/Jejak.html
>
> During the VALMADEO project (a PRIR/Région Bretagne funded project directed
> by C. Dezan, <[hidden email]>), we needed a tool to study in detail how
> some algorithms (error correcting codes) could work without errors, but with
> degraded performance. Execution and compilation would report no errors, but
> the performance of the error correcting coding and decoding would be several
> dB below the target. The error correcting code was looping hundreds of times
> over each block of data, making step by step debugging unusable. Profiling,
> message tallies were too coarse to tell us anything. We needed a different
> tool.
>
> The answer was this trace tool : a framework for injecting probes into
> methods, and record their execution. It can record an execution to the
> smallest detail (all calls, all values, all assignments), that over a long
> sequence (hundreds or thousands of calls), and let one navigate freely
> through the recorded trace along with the traced source code. It is capable
> of tracing system, startup or display methods, without interruption or
> blocking the overall image, allowing for very fine non-intrusive system
> analysis.

> I announce the first availability of the Jejak trace framework at
>
> http://ss3.gemstone.com/ss/Jejak.html
>
> During the VALMADEO project (a PRIR/Région Bretagne funded project directed
> by C. Dezan, <[hidden email]>), we needed a tool to study in detail how
> some algorithms (error correcting codes) could work without errors, but with
> degraded performance. Execution and compilation would report no errors, but
> the performance of the error correcting coding and decoding would be several
> dB below the target. The error correcting code was looping hundreds of times
> over each block of data, making step by step debugging unusable. Profiling,
> message tallies were too coarse to tell us anything. We needed a different
> tool.
>
> The answer was this trace tool : a framework for injecting probes into
> methods, and record their execution. It can record an execution to the
> smallest detail (all calls, all values, all assignments), that over a long
> sequence (hundreds or thousands of calls), and let one navigate freely
> through the recorded trace along with the traced source code. It is capable
> of tracing system, startup or display methods, without interruption or
> blocking the overall image, allowing for very fine non-intrusive system
> analysis.

> I announce the first availability of the Jejak trace framework at
>
> http://ss3.gemstone.com/ss/Jejak.html
>
> During the VALMADEO project (a PRIR/Région Bretagne funded project directed by C. Dezan, <[hidden email]>), we needed a tool to study in detail how some algorithms (error correcting codes) could work without errors, but with degraded performance. Execution and compilation would report no errors, but the performance of the error correcting coding and decoding would be several dB below the target. The error correcting code was looping hundreds of times over each block of data, making step by step debugging unusable. Profiling, message tallies were too coarse to tell us anything. We needed a different tool.
>
> The answer was this trace tool : a framework for injecting probes into methods, and record their execution. It can record an execution to the smallest detail (all calls, all values, all assignments), that over a long sequence (hundreds or thousands of calls), and let one navigate freely through the recorded trace along with the traced source code. It is capable of tracing system, startup or display methods, without interruption or blocking the overall image, allowing for very fine non-intrusive system analysis.
>
> It has been used for debugging turbo codes implementations, algorithm understanding on turbo codes, and memory behaviour analysis for embedded systems design space exploration.
>
> It requires The Opal compiler and is integrated with OmniBrowser, and is tested in a Pharo 1.4 image. Instructions for loading are :
>
> Gofer it
>    squeaksource: 'MetacelloRepository';
>    package: 'ConfigurationOfOmniBrowser';
>    load.
>
> (ConfigurationOfOmniBrowser
>    project version: #stable) load: #( 'Dev' 'Dev Tests').
>
> Gofer new
>     url: 'http://smalltalkhub.com/mc/MarcusDenker/Opal/main';
>     package:'ConfigurationOfOpalCompiler';
>     load.
>
> (Smalltalk at: #ConfigurationOfOpalCompiler) load.
>
> Gofer new
>    repository: 'http://ss3.gemstone.com/ss/Jejak';
>    load
>
> There is a lot left to be done (better event logging, out of image logging, performance issues), but, as it is, it can be used for tracing almost any code in the image, even ones which may lock-up the image when halted (beware : bugs in the tracer may still lock or crash the image). It is also a very pedagogic way of seeing a full execution through a set of methods.
>
> Thierry
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>
>

>
>> I announce the first availability of the Jejak trace framework at
>>
>> http://ss3.gemstone.com/ss/Jejak.html
>>
>> During the VALMADEO project (a PRIR/Région Bretagne funded project directed
>> by C. Dezan, <[hidden email]>), we needed a tool to study in detail how
>> some algorithms (error correcting codes) could work without errors, but with
>> degraded performance. Execution and compilation would report no errors, but
>> the performance of the error correcting coding and decoding would be several
>> dB below the target. The error correcting code was looping hundreds of times
>> over each block of data, making step by step debugging unusable. Profiling,
>> message tallies were too coarse to tell us anything. We needed a different
>> tool.
>>
>> The answer was this trace tool : a framework for injecting probes into
>> methods, and record their execution. It can record an execution to the
>> smallest detail (all calls, all values, all assignments), that over a long
>> sequence (hundreds or thousands of calls), and let one navigate freely
>> through the recorded trace along with the traced source code. It is capable
>> of tracing system, startup or display methods, without interruption or
>> blocking the overall image, allowing for very fine non-intrusive system
>> analysis.
>
> This means one could get branch coverage analysis, doesn't it?