[cc'ed to our list, ticket #35392 ]
> Dear Perl eating Parrots,
> I hope you are the appropriate person to send this email to.
Almost :) Please use perl6-i...@perl.org for replies or questions
> Will Perl 6 have a tracing API or will it rely on a tracing API in
It'll provide some interface and rely on Parrot.
> Will Parrot have a tracing API?
For sure, but this isn't speced yet. But parrot can already run with a
--trace (-t) option, which produce an opcode trace.
> Ideally a tracing API would provide the following:
> o Trace enter/exit of functions
> o Trace line visits
> o Trace exception events
> o Provide access to function parameters
> o Provide access to function return value(s) (for languages that support
> multiple return values).
> o Provide access to local variables
I'm pretty sure that we will cover all...
> o Memory/Object allocation
> o Memory/Object reallocation
> o Memory/Object moved (used by GC)
> o Memory/Object deallocation (during GC or explcitly by language
> o Garbage collect start
> o Garbage collect end
... including GC and memory stats, which are already supported.
> In addition to the above the tracing API would be well served by
> including the following multi-threading events (which are absent from
> Python/Ruby tracing and possibly absent from Lua/Tcl tracing).
> o Enter/Entered/exit monitor/synchronization event so that you can track
> which locks are pending acquisition/locked/released.
> o Starting Wait/Finished Wait
I can't say much about these, as the thread models aren't really fully
> I suppose an alternative would be an instrumentation API which would
> allow tool vendors to instrument the byte code. Java and .Net provide
> these - they also provide all of the above mentioned items (including
> the multi-threading and memory events).
Yep. instrumenting bytecode is for sure doable.
> I work for Object Media Limited. We implement software tools which are
> marketed by Software Verification. We provide Software Tools for
> Coverage, Performance, Flow Tracing and Thread Analysis for Python and
> Ruby. We will soon be extending this to include Memory Analysis tools
> for Python and Ruby.
> Software Verification's website is http://www.softwareverify.com
> We would like to support Perl 6/Parrot when it is possible to do so.
Please excuse the possible 'out of left field' (as we say) aspect of this
question but I recently heard about Omniscient Debugging (ODB):
There is an article in the latest Dr Dobbs (6/05) by the above fellow (Bil
Lewis - former Sun scientist and author of the GNU Emacs Lisp manual)-
he's got a java implementation of ODB. Basically every change to every
obj/var is tracked, so you can work back through the whole run in one try,
w/o the 'set breakpoint/rerun' sort of iterativeness that goes on,
normally. His story is that the JVM is esp. suited to doing this, making
the ODB quite easy, so I asked him about how to go about this for
"I took a peek at Parrot... It didn't say the "right" things about how
a VM should work, which worries me.
In any case, all you have to do is to have your code make the appropriate
calls into my recording functions everytime the appropriate event occurs.
I do this in Java with byte code insertion. Looks like this will be much
harder in the Parrot VM, but still possible.
It could be easier to do in the compiler, if you're good with compilers."
[ I asked what were the 'right things' ]
"The JVM, CLR, and ELisp are all stack machines and they work *really*
well. And being a stack machine makes a lot of stuff *really* easy to do.
As opposed to previous experience with VMs done as flat register machines.
Which have proven harder to work with.
Parrot tosses that out and fails to give a convincing argument why.
They talk about Perl being interpreted as important. It isn't. You
shouldn't even know what it's doing at that level."
I don't mean to quote him out of context or to start a stack vs register
debate, I was just hoping to get some idea from him what is needed to get
ODB to work, but didn't know if there was any hope for it in p6. The
lambdaCS site has the java jar/source and a nice enough demo of his
implementation, there are a couple of commercial apps:
both of which seem to be java only. It would seem to be a very useful
addition to the world of perl debugging, if it could be shoehorned in w/o
a horrible amount of work. However, I'm not the person to do the
"Outside of a dog, a book is man's best friend. Inside of a dog, its too
dark to read."
This seems to require almost the same journaling capacity for STM
(software transactional memory), although in STM's case we only mark
updates for "shared" variables, whilst in ODB a journal is kept for all
It is conceivable to build this facility into the PMCs, much like
how tied objects work, but my knowledge of parrot internals is
insufficient to answer whether it will be difficult or not.
Adding this sort of instrumentation is, however, much easier from a
compiler's point of view; all you need to do is to generate extra
instructions that records the timestamp, the variable being updated,
and its original value. It will require a recompilation, and the
result is difficult to share across different Parrot-targetting
languages, so it's the less optimal choice.
If you'd like to experiment with adding such instrumentation to Perl 6
(and history navigator, etc), I can give you a committer bit in Pugs --
you can do logged PMCs in the form of IVars, or by generating more
instructions in the AST evaluation layer. The latter approach can be
reused in the Parrot code generator, too.
Sounds very powerful
> This seems to require almost the same journaling capacity for STM
> (software transactional memory), although in STM's case we only mark
> updates for "shared" variables, whilst in ODB a journal is kept for all
> It is conceivable to build this facility into the PMCs, much like
> how tied objects work, but my knowledge of parrot internals is
> insufficient to answer whether it will be difficult or not.
I've already described in my summary http://xrl.us/f234 2.2) that we
should split the vtable into various parts. We should be able to
switch to a read-only variant of a PMC for example.
Switching in some vtable pieces that logs set_*_* vtable calls is more
or less the same thing.
vtable.tbl already has most of this information: see "[STORE]". There is
an experimental feature 'pmclass SArray const_too' in the SArray PMC,
where two vtables are created, switchable by setting the "_ro" property.
But this is all really rough and not a general solution.
 The vtable is currently almost 600 bytes (32bit system). By
switching full vtables just to get a read-only variant, we'd need a lot
of memory. And: a scalar PMC doesn't need nor implement the array-ish
vtable slots. I prefer one more indirection for almost all of the vtable