4 ms·

Both app size and startup time should improve greatly with Graal (or with Java 9's jlink or jaotc), the idea is to generate an executable with only the part of

Both app size and startup time should improve greatly with Graal (or with Java 9's jlink or jaotc), the idea is to generate an executable with only the part of the JRE and external libraries that the app really uses. There was some discussion on HN about this VM before (about performance with TruffleRuby, an implementation of Ruby on the JVM): https://news.ycombinator.com/item?id=13652541 https://news.ycombinator.com/item?id=13652541

nirvdrum 9y ago
If you're interested, I gave a talk at RubyConf a couple months back with updated info for TruffleRuby on the SVM: https://www.youtube.com/watch?v=hIMldcAzd5o https://www.youtube.com/watch?v=hIMldcAzd5o The SVM is a critical component in achieving some of our performance objectives for TruffleRuby, particularly when it comes to startup time and running code that hasn't warmed up yet. Short-lived applications have always been something of an Achilles heel for dynamic languages targeting the JVM. The SVM provides a nice way of solving that problem as long as your program can operate with its restrictions (e.g., no dynamic class loading). From a positioning perspective, I think an interesting aspect of the SVM is TruffleRuby is no longer an implementation of Ruby on the JVM. It's an implementation of Ruby written in Java for sure, but the JVM isn't required.
SureshG 9y ago
> only the part of the JRE and external libraries that the app really uses Just curious, how the reflection and dynamic class loading things work when generating an executable?
- nirvdrum 9y ago
  The native image generator performs a closed-world static analysis over your application, the JDK, and any supplied libraries to determine what's actually in use. In cases of ambiguity, it must be conservative and include all candidate classes. Since the output is a native binary without the JVM (and subsequently, without a Java bytecode interpreter), there's no way to dynamically load classes. Reflection is handled by registering classes during the image generation process, I believe. Static MethodHandles neatly avoid any issues as well, if you can work with that.

nirvdrum 9y ago

If you're interested, I gave a talk at RubyConf a couple months back with updated info for TruffleRuby on the SVM: https://www.youtube.com/watch?v=hIMldcAzd5o https://www.youtube.com/watch?v=hIMldcAzd5o The SVM is a critical component in achieving some of our performance objectives for TruffleRuby, particularly when it comes to startup time and running code that hasn't warmed up yet. Short-lived applications have always been something of an Achilles heel for dynamic languages targeting the JVM. The SVM provides a nice way of solving that problem as long as your program can operate with its restrictions (e.g., no dynamic class loading). From a positioning perspective, I think an interesting aspect of the SVM is TruffleRuby is no longer an implementation of Ruby on the JVM. It's an implementation of Ruby written in Java for sure, but the JVM isn't required.

SureshG 9y ago

> only the part of the JRE and external libraries that the app really uses Just curious, how the reflection and dynamic class loading things work when generating an executable?

nirvdrum 9y ago
The native image generator performs a closed-world static analysis over your application, the JDK, and any supplied libraries to determine what's actually in use. In cases of ambiguity, it must be conservative and include all candidate classes. Since the output is a native binary without the JVM (and subsequently, without a Java bytecode interpreter), there's no way to dynamically load classes. Reflection is handled by registering classes during the image generation process, I believe. Static MethodHandles neatly avoid any issues as well, if you can work with that.