Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Whiteknight (8626)

Whiteknight
  (email not shown publicly)
http://en.wikibo ... User:Whiteknight
AOL IM: wknight8111 (Add Buddy, Send Message)

My name's Andrew. I'm an open-content advocate at http://en.wikibooks.org. I'm also involved with Parrot as a semi-competent C hacker. This blog is going to be a forum where I can ramble about minutia and post information about perl-world stuff that I care about.

Journal of Whiteknight (8626)

Saturday April 18, 2009
05:59 PM

JIT on Parrot

[ #38827 ]

The JIT system on Parrot is a little bit of a mess, and one that has been mostly ignored for a while now, except for the increasingly-frequent occasions when it breaks.

So far back as 2004 people in Parrot were talking about libJIT but decided it made more sense to use a custom-made JIT backend solution that was targeted to the idiosyncracies of Parrot "from day 1". Several years later, with the release of 1.0.0 slowly fading into the distance behind us, our custom-built system is not only no better then libJIT or LLVM for our specific needs, and is more likely to need to be completely scrapped and rewritten for it to be useful at all. Plus, JIT is only implemented on i386, which is only a small portion of our target systems.

Parrot's JIT system is a complicated one. Parrot hands over the current bytecode stream to the JIT engine, which in turn compiles the bytecode into native machine code and executes it. It does this by maintaining a large list of Regex-based definitions for opcodes, and writing the glue code necessary to pass between them and the other parts of Parrot (the PMC system vtables, for instance). This system requires that we write, from scratch and with minimal abstractable overlap, a new JIT engine for each system we want to support.

An engine like LLVM or libJIT (or even GNU Lightning, although I don't know as much about that project immediately simplifies everything. We can write the solution once, and have it just work on all platforms where the JIT backend system is supported (which, at the moment, is almost a superset of all the platforms that Parrot supports, for both engines). Plus, for both engines, we suddenly get all the benefits while only having to write one interface: automatic machine code generation and execution, cross-platform stability, and code optimization. It's like a win-win for us!

Tewk++ submitted a very interesting application to GSOC to implement an LLVM-based JIT system for Parrot. I don't know when winning projects get announced, but if he's in that group I'm sure I'll post a short hallelujah here. I've also been doing some looking into libJIT myself, and might dabble with that concurrently. Having a good JIT engine in Parrot would be very good, but having a sane interface that would support multiple JIT cores would be great.

In the meantime, my opinion is that our current JIT system should be ripped out wholesale. We don't really have a working system currently, just the illusion of one. It doesn't work on all our target systems, and where it does work it is fragile and messy and unreliable. It's better to admit to ourselves that we don't currently have an acceptable JIT solution. Hopefully, that realization will galvanize us into implementing a real JIT post haste.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I found out this morning that the JIT system for PPC is also working. I wasn't aware of that previously. So, there are actually two platforms supported by JIT, not just one like I suggested in the post.

    --
    Andrew Whitworth