3 ms·

I wonder how the performance and size of apps compiled with Graal compares with traditional Java apps ?

by stuaxo 9y ago

mike_hearn 9y ago
Graal can be used with "traditional" HotSpot, in which case the user would observe no particular difference in (download/disk) sizes. But this article is about SubstrateVM, which is a JVM that links itself with the program being run and throws out the rest. You can get very small program sizes this way, comparable to Go.
loopbit 9y ago
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.

I wonder how the performance and size of apps compiled with Graal compares with traditional Java apps ?

by stuaxo 9y ago

I wonder how the performance and size of apps compiled with Graal compares with traditional Java apps ?

Graal can be used with "traditional" HotSpot, in which case the user would observe no particular difference in (download/disk) sizes. But this article is about SubstrateVM, which is a JVM that links itself with the program being run and throws out the rest. You can get very small program sizes this way, comparable to Go.

loopbit 9y ago

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.