GSoC 2010 Idea: Instrumenting Framework

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


Howdy,

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 irc.perl.org to get more feedback from developers. As
always, if  you have questions about Parrot internals, send questions
to this mailing list.

Duke




On Mon, Mar 22, 2010 at 10:34 AM, Muhd Khairul Syamil Hashim
<khairulsyamil at gmail.com> 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, www.dynamorio.org).
>
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net


More information about the parrot-dev mailing list