Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby+OMR JIT Compiler: What’s Next?

developer.ibm.com

Post reply on HN
Print view View original

1–10 of 38 posts

Re: Ruby+OMR JIT Compiler: What’s Next?

#6

Post by magaudet »

crudbug wrote: post #3

Eclipse OMR is interesting, it provides good platform abstraction with support for threading, monitoring, etc. Can you create new native languages using Eclipse OMR ?

When you say "native languages" you mean a statically compiled language?

It's been done before with the technology underlying the OMR compiler component, however there is some work that would need to be done to support this.

In principle though, there's no reason it couldn't be done.

Re: Ruby+OMR JIT Compiler: What’s Next?

#8

Post by crudbug »

magaudet wrote: post #6
crudbug wrote: post #3

Eclipse OMR is interesting, it provides good platform abstraction with support for threading, monitoring, etc. Can you create new native languages using Eclipse OMR ?

When you say "native languages" you mean a statically compiled language? It's been done before with the technology underlying the OMR compiler component, however there is some work that would need to be done to support this. In principle though, there's no reason it couldn't be done.

Yes, I meant "statically typed" similar to swift.

I was thinking, OMR providing the native platform semantics that will enable multiple language syntaxes.

Re: Ruby+OMR JIT Compiler: What’s Next?

#9

Post by rurban »

> In Evan’s keynote, he proposed a really interesting and ambitious solution to the problem he called “lifting the core.” It involved shipping Ruby with LLVM intermediate representation of the CRuby functions to allow the LLVM JIT technology to look inside the CRuby functions and dramatically increase the optimization horizon. As far as I know, this hasn’t been attempted yet — although, if it has, I really want to see it!

Actually unladen_swallow and cperl are doing this. Compile the whole runtime to a lib.bc (trivial make rule), load this bitcode file (a single call), and add the expensive optimizations, esp. the inliner and IPO in llvm. Just the type-checks need to be done in the jit. This inliner does a lot of good magic esp. for the small RT functions. >10x faster.

The compiler is expensive though (i.e. very slow), and LLVM changed it's jit API 3 times already. = 3.6 ocrjit, all 3 of them still having major quirks.

With mcjit you cannot selectively add jit code to a module. So every single body needs to be a new module. So module != package/class/namespace. So the jitcache is a bit complicated. With the latest ocrjit you got problems in finding the symbols in the bc. The C API doesn't support the name resolver at all, and it's a major quirks with C++. LLVM's C API is really behind, but at least they don't change it that often as the C++ API.

unladen_swallow has a huge JIT overhead library, which nobody really needs.

For the cperl jit I just used 4 days so far and doesn't even link yet. I used the C API, not the better C++ API. No C++ for cperl. But it's very simple. https://github.com/perl11/cperl/blob/feature/gh220-llvmjit/j...

Re: Ruby+OMR JIT Compiler: What’s Next?

#10

Post by chrisseaton »

rurban wrote: post #9

> In Evan’s keynote, he proposed a really interesting and ambitious solution to the problem he called “lifting the core.” It involved shipping Ruby with LLVM intermediate representation of the CRuby functions to allow the LLVM JIT technology to look inside the CRuby functions and dramatically increase the optimization horizon. As far as I know, this hasn’t been attempted yet — although, if it has, I really want to se…

Wow I had no idea anyone was shipping bitcode of their runtime for dynamic compilation. Are there any blog posts, papers, etc about it? Does it work well?
Post reply on HN