4 ms·
I'm pumped for startup improvements, it's about the only downside to JRuby. Does the ability to use Java libraries with TruffleRuby go away with SubstrateVM th
by rubyfan 10y ago
I'm pumped for startup improvements, it's about the only downside to JRuby.
Does the ability to use Java libraries with TruffleRuby go away with SubstrateVM though?
- deleted 10y ago[deleted]
- chrisseaton 10y agoYou have to compile the Java libraries that you want to use into your binary, or we're looking at doing a Java bytecode interpreter in the same manner as our Ruby interpreter.
- samandmoore 10y agoI think that's a fair trade off. If people want to use Java and ruby together without having to worry about that precompilation step then there is still standard JRuby. I really like the idea of TruffleRuby becoming its own super fast Ruby implementation unhindered by the need to provide the same feature set as JRuby.
- ehsanu1 10y agoWell you'd only use SubstrateVM when deploying to production, so I don't know why anyone wouldn't want to "worry about that precompilation step". During development it should be irrelevant. Or am I missing something here?
- nirvdrum 10y agoIn an ideal world, you'd use the same Ruby for development and production -- you just get more predictable results that way. With SubstrateVM, we're addressing the startup time issue that usually drives a team to have different Ruby implementations in development and production. If you have another use case for split dev/production environments, please let me know. A limitation of the SubstrateVM build is you can't just start calling code in a JAR you load at runtime -- that needs to be built into the image. A common use case for JRuby is as a really awesome shell to Java. You won't have that capability with SubstrateVM because we can't load arbitrary Java code at runtime. Likewise, you couldn't just swap out JARs with different implementations of interfaces on the fly (e.g., JDBC usage patterns). And JRuby can load gems that themselves have Java code in them, which also wouldn't work (setting aside the fact we also don't support their extension API).
- ehsanu1 10y agoThanks, I was confusing myself there. Obviously you would really want to use SubstrateVM in development to get that sweet fast startup - I'm just blind to the startup time angle since I use the zeus gem to keep my application always already started up and fork off new processes as needed. I was considering the case of building a single executable, including the entire ruby application and its dependencies, via SubstrateVM. This could make deployment a lot simpler.
- rubyfan 10y agoInteresting, I'm really poking forward to this maturing. This is exciting news for Ruby to be sure.
- BenoitP 10y agoOn an unrelated topic, will TruffleRuby have all the OpenJDK's GC algorithms available? I'm thinking of Shenandoah specifically. I understand they depend on inserting barriers with JVMCI, so I'm hopeful for compatibility. How is SubstrateVM build? It is made out of using the OpenJDK code base in a specific manner?
- chrisseaton 10y agoI don't think we have the barriers for Shenandoah yet. It would be easy enough to add them I believe. SVM is a new VM implemented in Java. It isn't made from the OpenJDK's native implementation in C++.
- zigzigzag 10y agoIf that's the case surely it doesn't matter if you have the barriers for Shenandoah, as it's written in C++ for HotSpot. Wouldn't you have to rewrite it from scratch in Java for SubstrateVM?
- chrisseaton 10y agoYes for SVM having the barriers won't help. But I read the question as about TruffleRuby in general, which can run on OpenJDK where Shenandoah is available.
- zigzigzag 10y agoGraal already can compile bytecode, right, so I don't get why SubstrateVM finds it so hard to dynamically load code but a truffle java bytecode interpreter would work
- chrisseaton 10y agoGraal compiles bytecode, but it doesn't class load it, verify it, interpret it, profile it, etc etc.