LLJVM

da.vidr.cc

67 points·njn··11 comments

This is a massive improvement over the old way of doing this -- use a $LANG compiler targeting 32-bit MIPS and then emulate that processor in Java (not too hard as the memory models match up).

One of the big challenges facing the JRuby community today is the prevalence of gems with C extensions. For gems where the C source is available, this might be a viable route to compatibility.

For anyone trying to crack that problem, this is definitely worth deeper investigation.

if the performance is acceptable, sure, why not.

This would require a compatibility layer for the MRI C API, which would be difficult but probably doable.

It would only solve part of the problem, though: many of the C extensions exist as bindings to existing C libraries. This wouldn't solve that unless the entire library were compiled this way.

There's libffi for the latter problem, though. It's still work, obviously, but probably less.

There's also NestedVM, http://nestedvm.ibex.org/, which works my using gcc to cross compile to MIPS and then convert the MIPS machine code into a Java class file.

Someone actually just posted the llvm development mailing list with a backend they wrote for LLVM so that it can generate JVM bytecode (in the same way in generates x86, PPC, etc.) and it uses this lib, cool stuff.

That's the same guy.

Is this an alternative to JNI?

Not really. I guess you could, in cases where you had the C source code, and were happy to compile everything into bytecode (including all that C codes dependencies with it). You wouldn't be running native code any more unlike JNI. JNA would be considered an alternative.

C on the JVM? Dear me!

Reply on news.ycombinator.com