GSoC report

Jonathan "Duke" Leto jonathan at
Thu Jul 25 22:52:27 UTC 2013


This is a great level of detail! Please keep it up :)


On Tue, Jul 23, 2013 at 11:40 AM, Paweł Murias <pawelmurias at> wrote:
> While trying to get QASTNode.nqp to compile I noticed a strange error
> claiming that some code refs where missing from the serialization context.
> By binarysecting the file (deleting line till the error goes away) it turned
> out that roles in modules where causing problems. Serializing roles requires
> serializing a closure, and modules are special that they require to be
> compiled twice, both to JavaScript and PIR (that is untill we are fully
> boostraped).
> The thing that turned out to be causing trouble is that the JavaScript
> backend is using a slightly different bootstraping procedure.
> The way Jonathan did it was to compile a given file first to pir and
> starting the compiler again and compiling to the JVM (or in our case
> JavaScript). A special --stable-sc option is used to make sure the ids of
> the serialization context match.
> That means an object can be deserialized at compile time (for example when
> it's loaded from the bytecode file containing the setting). The compiler can
> then emit a reference to it (marking which serialization context it was
> loaded from and under which index it's stored it). When we then load it at
> runtime from an serialization context kept in a javascript file with the
> identical id. We assume both the compiler runs where deterministic so the
> both of the serialization context have identical content. If we do
> nondeterministic things at compile time (like my $foo := BEGIN random()),
> bad things will happen, so we don't.
> The approach I have taken is to parse the code once, and pass the AST to two
> different
> backends
> .
> The problem with that is both of the backends serialize the serialization
> contexts.
> And the context serialization code marks attaches some info onto closures.
> It really makes sense to serialize the compilation context once (as it's
> assumed to be immutable after serialization).
> So I set to introduce some caching.
> First I tried to but the caching inside
> QAST::CompUnit
> Jonathan however felt that I was puting stuff into nodes which shouldn't
> concern them.
> So I planned a redesign of the serialization opcodes to implement it more
> elegantly. Seeing that Jonathan explained that instead of pushing the
> changes deeper and deeper I should hack this on without tangling it up with
> the rest of the code.
> For now I'm using a branch, but it seems to be possible to easily monkey
> patch the compiler to introduce a contextual.
> To shake out bugs and find things to test I started writing some unit tests
> for bits of qast
> _______________________________________________

Jonathan "Duke" Leto <jonathan at>
Leto Labs LLC

More information about the parrot-dev mailing list