- I don't have a particular preference for using LLVM or libJIT in Parrot. Both have associated pros and cons. Either solution (or even GNU Lightning, which hasn't been mentioned as regularly) would be far superior to what we have now.
- Our opcode files are written in a C-like superset, and our JIT system is responsible for providing secondary definitions of them as well. Change an opcode file without changing the corresponding JIT definition, you break JIT. Instead, what we should do is generate the JIT definitions automatically from the opcode definition files. This means that we probably can't write the opcodes in C (unless we can find a good translation engine from arbitrary C code to JIT code emitters). Begs the question: What would be the smallest number of operation primitives we would need in order to implement our various operations in a way that could be translated both to C and JIT definitions at build time?
- I took another long look at the Boehm collector today, and I learned something interesting that I did not know previously: The collector allows custom finalization methods to be run on destroyed data objects. This comes with some caveats, not the least of which is that finalizers of reachable objects are not run prior to program termination. This is rectifiable if we maintain a list of PMCs that absolutely must be finalized, and run through that list manually in Parrot_exit. I also don't think there is any guarantee about order-of-destruction when we're calling finalizers, so that can raise some problems for us. In any case, it's definitely doable, and a Boehm-based GC core could probably be a reality for Parrot in the not-to-distant future.
Friday, April 17, 2009
A lot of talk about JIT has been going on lately in Parrot world. Tewk submitted a very cool looking proposal to implement an LLVM-based JIT backend. We received another post to the list about libJIT. Here are some of my general Parrot-related thoughts right now:
at 7:47 PM