GSoC 2010 Idea: Instrumenting Framework

Jonathan Leto jaleto at
Mon Mar 22 19:26:41 UTC 2010


This looks like a start to a good proposal, Khairul. Could you provide
some specific examples of what kind of instrumenting code you could
get done by the end of the summer? I invite you to #parrot and
#soc-help on to get more feedback from developers. As
always, if  you have questions about Parrot internals, send questions
to this mailing list.


On Mon, Mar 22, 2010 at 10:34 AM, Muhd Khairul Syamil Hashim
<khairulsyamil at> wrote:
> Hi there,
> I should introduce myself.
> My name is Khairul and I'm currently a Year 3 student studying at the
> National University of Singapore (NUS), majoring in Computer Engineering.
> I currently have an idea for the 2010 Google Summer of Code (GSoC 2010),
> which is to implement a simple framework for instrumenting code that runs
> on Parrot. This is in the vein of DTrace and DynamoRIO (a dynamic
> instrumentation tool platform,
> I think having such a tool will be a boon to Parrot and languages that
> implement on top of Parrot. With instrumentation, we can inspect the flow
> of the program dynamically, setting up triggers on certain environment
> conditions, etc. This will assist in debugging the system, potentially
> providing more information than just debugging or tracing the program.
> This can also serve as a basis for more tools, with Valgrind  and its
> tools as an example.
> As such, this is my proposal. I would like to embark on a project for
> GSoC to create a tool that will take in 2 arguments, the first is the
> source file to execute and instrument against, and the other, a file
> containing the instrument callbacks that will be called on certain events.
> The tool will consist of 2 Parrot interpreter environments, one to run the
> file and the other for the instruments. This will prevent the instruments
> from contaminating and interfering with the execution environment. By
> utilizing an interpreter for the instruments, we can use languages supported
> on Parrot to implement the instruments. I think the tracing runcore can be
> leveraged and modified to provide the hooks for calling the instruments,
> given that it is already tracing and dumping all instructions.
>                                    +---+ +---+ +---+ +---+
>                                    | A | | B | | C | | D |   <- Various
> +------+                           +---+-+---+-+---+-+---++   instruments
> | Code |                           | Instrument Interface |  <- Interface
> +------+------+                    +----------------------+   to register
> | Interpreter |  ----------------> |      Interpreter     |   callbacks (PIR)
> +-------------+  Hooks activated   +----------------------+
>  [ Hopefully the diagram doesn't get garbled ]
> Of course, this is a simplistic overview.I shall admit that I have only
> recently started looking at Parrot when I heard about the announcement of
> GSoC 2010. As such, my understanding of Parrot and its internals may not
> be sufficient for now. I have spent the past few days looking through the
> source for Parrot and suspect will spend more time over the coming days,
> classes and workload permitting, figuring out Parrot's internals and PIR.
> I would greatly appreciate any thoughts or comments regarding this.
> Regards,
> Khairul
> _______________________________________________

Jonathan "Duke" Leto
jonathan at

More information about the parrot-dev mailing list