[Pharo-project] [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, <dezan@univ-brest.fr>), 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
On 18 July 2012 13:55, Goubier Thierry <thierry.goubier@cea.fr> wrote:
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, <dezan@univ-brest.fr>), 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? frank
Yes. It would be easy to do. How it would work as Jejak is now. Trace as it is, scan the trace with an AST visitor (or just the reference on all branches in the original code). Jejak provides: the probe writer for traces, an AST visitor to relate a trace event to the original source code, and trace visitors (for trace transformation and filtering). Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Frank Shearar [frank.shearar@gmail.com] Date d'envoi : mercredi 18 juillet 2012 18:28 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] [ANN] The Jejak Trace framework On 18 July 2012 13:55, Goubier Thierry <thierry.goubier@cea.fr> wrote:
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, <dezan@univ-brest.fr>), 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? frank
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, <dezan@univ-brest.fr>), 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?
We could then build a branch analysis of tests.
Excellent. Thanks for releasing this code. Stef
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, <dezan@univ-brest.fr>), 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
participants (4)
-
Frank Shearar -
GOUBIER Thierry -
Goubier Thierry
-
Stéphane Ducasse