Hi! It’s timotimo again and this week we’re pretty stoked to present some really neat stuff to you!

jnthn implemented finalizer support (giving your classes a DESTROY method or submethod that will be invoked when the object gets collected by the GC) on MoarVM and exposed it to rakudo. Now nine will be in a much better position to work on the Inline::Perl5 module!

Speaking of Inline::Perl5, carlin contributed changes to the module that make it installable via Panda, so it doesn’t require any manual work any more.

brrt implemented a little function to force a GC run on MoarVM. It’s not meant for performance tuning, though. Its main purpose is to help write test cases that check the behavior of DESTROY methods and similar things.

MoarVM now properly reports errors when mallocing memory fails instead of just crashing, thanks to carlin.

carlin also fixed up some cases where signedness vs. unsignedness caused branches to always or never be taken in MoarVM’s guts.

brrt taught the JIT log to write out where inlines happened in the code.

I implemented bindattrs_* (bind a value to an instance’s attribute given a string that’s not known at compile time) and getattrs_* in the JIT.

MoarVM’s GC used to run a full collection through nursery and old generation every 25 runs. Now it counts how much data has been promoted to the old generation since the last time a full collection was done and bases the decision on that fact. I started the patch, jnthn gave it the finishing touches.

cognominal worked on the Synopsis 99 a whole lot. If you’re ever puzzled by lingo from the Perl 6 community (for example on this blog), this document lends you a helping hand.

The usual assortment of spec test improvements have also happened, of course.

In the ecosystem, leont contributed a TAP::Harness module and grondilu added Clifford, a geometric algebra module and btyler built a NativeCall binding to “discount”, a markdown compiler.

Another topic that got a lot of attention by the devs this week is performance of specific things that were currently implemented quite sub-optimally and gave users a very bad experience in common usage scenarios:

All it takes for the devs to start a little performance hack-a-thon is a good, reproducable benchmark with a comparison to another language.

Until The Big List Refactor has happened, the performance of lists, list iteration, lazy lists and so on are going to be suboptimal, as we almost always pay the price for a fully lazy list generation, even when the iteration can be identified to be eager.

Another thing to note is that the name “DESTROY” is not yet final. There’s some discussion about it still, because calling it DESTROY may give people familiar with perl5 a bad idea. As opposed to a reference counted implementation (like CPython or perl5), fully garbage-collected implementations (like PyPy and Rakudo) cannot guarantee that your DESTROY methods are called soon after the object becomes unreachable. The DESTROY method may not even be called at all if the interpreter shuts down before that particular object gets collected. If you want your destruction timely and guaranteed, you’ll have to “do it yourself”.

Either way, it’s been a great week for both performance and feature advances. I’ll be back in a week, or maybe I’ll run benchmarks tonight and just publish an out-of-schedule post here with my results 🙂

See you around!