Skip to content

Experimental JIT compiler - #3292

Closed
z0w0 wants to merge 10 commits into
rust-lang:incomingfrom
z0w0:jit3
Closed

Experimental JIT compiler#3292
z0w0 wants to merge 10 commits into
rust-lang:incomingfrom
z0w0:jit3

Conversation

@z0w0

@z0w0 z0w0 commented Aug 28, 2012

Copy link
Copy Markdown
Contributor

This is my 3rd attempt to get this working over around 4 months. It's working pretty well compared to last attempts.

I've found that it runs perfectly (slow parsing/compiling times, fast executing times) with most tests running fine. Most benchmarks actually run faster than statically compiled executables! Of course, it's not perfect yet and there are some issues:

  • No crates are explicitly linked in yet - this is easy to do code-wise, the issue is llvm::sys::DynamicLibrary::LoadLibraryPermanently is segfaulting when I try and load crates. The code to do this (pretty simple) is commented out and ready to be fixed (I imagine the fix is something simple)
  • std and core are the only crates available because of above - they're only available because the JIT compiler uses dlsym to resolve symbols from the main program and any loaded crates - hence it loads the std and core crates used by rustc. This is not a good idea, as users may want to use specific versions of the core libraries, so it has to be fixed with above
  • Running some code/tests or using --test results in terminate called after throwing an instance of 'rust_task*' - I do not know enough to understand what's causing that
  • Minor/easy thing: You can't pass along arguments to the jitted program yet

These issues can easily be fixed in patches (I'll investigate the first two issues) but I'm not sure about the 3rd one. #rust were pretty keen to see this pulled upstream and I think it's ready for that.

Also important to mention is I based the memory manager source code on LLVM's lli tool (most of the original comments remain) because it worked well with what was needed and it had fixed issues that I knew were going to be hit (also it was the only good example of JIT memory managers that I could find - MCJIT managers require them in order to run). Not sure what sort of things need to be done there in terms of licensing / credits / etc.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants