HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
Using LLVM and Sulong for Language C Extensions - LLVM Cauldron 2016

Embecosm · Youtube · 1 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention Embecosm's video "Using LLVM and Sulong for Language C Extensions - LLVM Cauldron 2016".
Youtube Summary
Chris Seaton - Oracle Labs
Many languages such as Ruby, Python and JavaScript support extension modules written in C, either for speed or to create interfaces to native libraries. Ironically, these extensions can hold back performance of the languages themselves because the native interfaces expose implementation details about how the language was first implemented, such as the layout of data structures. In JRuby+Truffle, an implementation of Ruby, we are using the Sulong LLVM bitcode interpreter to run C extensions on the JVM. By combining LLVM's static optimizations with dynamic compilation, Sulong is fast, but Sulong also gives us a powerful new tool - it allows us to abstract from normal C semantics and to appear to provide the same native API while actually mapping it to our own alternative data structures and implementation. We'll demonstrate Sulong and how we're using it to implement Ruby C extensions.
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Graal only knows about JVM bytecodes, and there isn't any emulation of pointer arithmetic.

You need first to understand the role of Truffle in this.

It is a framework to generate AST interpreters, that plugs into Graal.

So an interpreter for LLVM gets written in Truffle, which while running a specific LLVM application, generates an interpreter for that specific code, so after awhile the JIT comes into the picture optimizing the generated interpreter that is processing that LLVM code.

This goes a few rounds until it becomes almost indistinguishable from generating the code straight from LLVM.

It is the same principle behind using PyPY and RPython to add new languages into PyPy.

JRuby is one of the projects making use of this infrastructure to run C extensions.

Naturally due to the slow startup until everything is finally converted into native code, this approach is only usable for long lived server based applications.

You can get more information about it in some of these links, mostly outdated though.

https://llvm.org/devmtg/2016-01/slides/Sulong.pdf

"Using LLVM and Sulong for Language C Extensions - LLVM Cauldron 2016"

https://www.youtube.com/watch?v=bJzMfYX6n9A

"Project Sulong: an LLVM bitcode interpreter on the Graal VM"

https://www.youtube.com/watch?v=yyDD_KRdQQU

int_19h
Regardless of how it gets there in the end - from an interpreter or otherwise - if it produces pure JVM bytecode, that means that the memory model is also JVM. How does that accommodate the C memory model? Emulating heap with giant arrays?
pjmlp
Most likely yes, which doesn't matter, because Graal will eventually optimize bounds check away anyway, as it does for regular Java code.

The links that I provided go into detail about all of this.

HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.