Look, I appreciate the engineering, but I'm genuinely curious if you think taking the JVM + building a MRI-compatible stack with C-transpilation is the perfect first order goal.
I'm not sure why you refer to Jruby ext api as a can of worms - perhaps there is some VM level dragons that I'm not aware of... but the Jruby ecosystem is brilliant. I built my first software services startup on top of Jruby - custom enterprise software that runs on Tomcat (the idea came from Mingle - a JRuby based enterprisey Basecamp from Thoughtworks)
Even in a general usecase, Jruby is brilliant when used with Puma. This deployment is unbeatable by any other ruby server. However, startup times in the java world is definitely a pain.. which is why developers tend to use MRI. In fact I know lots of developers who develop in MRI and deploy in jruby.
I think if you decide to take the direction of building a jruby compatible implementation with MRI beating startup times and with even one fourth of the performance you are talking about... tell me where to sign the cheque ;)
Hi there - no problem. Feel free to ask any question you'd like. You're not going to hurt our feelings and we'd rather clarify any confusion than let it linger and manifest into some weird FUD. On that note, we're quite active in the JRuby IRC and gitter rooms, so you ever have a question you want answered more real time, feel free to hop in and ask away.
The "can of worms" comment wasn't meant to be pejorative -- only that there's a lot to the problem and it's not exactly clean. There simply isn't an extension API in JRuby. There's just the JRuby JAR and whatever is publicly reachable.
The situation today is there are two backends available for JRuby: the standard IR-based one and the Truffle-based one. The two backends make use of shared infrastructure, but are otherwise quite distinct. E.g., both backends have different object models for Ruby-level classes & objects. Take Ruby strings for instance. They use a shared abstraction for the underlying implementation, but there's no shared interface -- it's all composition. Creating a Ruby string in a Java extension means importing org.jruby.RubyString and creating an instance of it. JRuby+Truffle represents strings differently, so creating a string that way presents a problem.
The simplest thing to do is translate everything between the two runtimes, but that incurs a lot of overhead, unnecessary object allocations, and grossly limits our ability to optimize calls. The harder solution is to provide a JRuby+Truffle implementation of the API, but given its current lack of definition, we'd have to support the de facto API for 100% compatibility and the de facto API is massive. We're working with the JRuby core team to annotate a portion of the API to be used for extensions, at which point the problem becomes much easier to manage.
FWIW - Prior to joining Oracle Labs I made a big gamble on JRuby for my start-up (Mogotest). I love JRuby and have been working with it for years outside of my current gig. I'd love to see JRuby+Truffle simply work with Java extensions, because they can be really nice (JDBC + Sequel is amazingly fast). Unfortunately, it's just a messy issue at the moment.
May I suggest a blog post on this. What you have written here on HN has been far,far more interesting than the original blog post and is making me excited to dive into the source code.
Comments
hi - thanks for taking the time to answer.
Look, I appreciate the engineering, but I'm genuinely curious if you think taking the JVM + building a MRI-compatible stack with C-transpilation is the perfect first order goal.
I'm not sure why you refer to Jruby ext api as a can of worms - perhaps there is some VM level dragons that I'm not aware of... but the Jruby ecosystem is brilliant. I built my first software services startup on top of Jruby - custom enterprise software that runs on Tomcat (the idea came from Mingle - a JRuby based enterprisey Basecamp from Thoughtworks)
Even in a general usecase, Jruby is brilliant when used with Puma. This deployment is unbeatable by any other ruby server. However, startup times in the java world is definitely a pain.. which is why developers tend to use MRI. In fact I know lots of developers who develop in MRI and deploy in jruby.
I think if you decide to take the direction of building a jruby compatible implementation with MRI beating startup times and with even one fourth of the performance you are talking about... tell me where to sign the cheque ;)
Hi there - no problem. Feel free to ask any question you'd like. You're not going to hurt our feelings and we'd rather clarify any confusion than let it linger and manifest into some weird FUD. On that note, we're quite active in the JRuby IRC and gitter rooms, so you ever have a question you want answered more real time, feel free to hop in and ask away.
The "can of worms" comment wasn't meant to be pejorative -- only that there's a lot to the problem and it's not exactly clean. There simply isn't an extension API in JRuby. There's just the JRuby JAR and whatever is publicly reachable.
The situation today is there are two backends available for JRuby: the standard IR-based one and the Truffle-based one. The two backends make use of shared infrastructure, but are otherwise quite distinct. E.g., both backends have different object models for Ruby-level classes & objects. Take Ruby strings for instance. They use a shared abstraction for the underlying implementation, but there's no shared interface -- it's all composition. Creating a Ruby string in a Java extension means importing org.jruby.RubyString and creating an instance of it. JRuby+Truffle represents strings differently, so creating a string that way presents a problem.
The simplest thing to do is translate everything between the two runtimes, but that incurs a lot of overhead, unnecessary object allocations, and grossly limits our ability to optimize calls. The harder solution is to provide a JRuby+Truffle implementation of the API, but given its current lack of definition, we'd have to support the de facto API for 100% compatibility and the de facto API is massive. We're working with the JRuby core team to annotate a portion of the API to be used for extensions, at which point the problem becomes much easier to manage.
FWIW - Prior to joining Oracle Labs I made a big gamble on JRuby for my start-up (Mogotest). I love JRuby and have been working with it for years outside of my current gig. I'd love to see JRuby+Truffle simply work with Java extensions, because they can be really nice (JDBC + Sequel is amazingly fast). Unfortunately, it's just a messy issue at the moment.
Thank you - you have been incredibly patient!
May I suggest a blog post on this. What you have written here on HN has been far,far more interesting than the original blog post and is making me excited to dive into the source code.
Glad it was helpful. I do need to start blogging more. 2016!