Truffleruby: Startup....

[ylluminate]

While I've been talking with many people about Truffle, one issue keeps popping up immediately when the discussion is brought around to using the JVM: What about startup speed?

Beyond simple general execution speeds, the #1 concern that Crystal has brought to the very front of the line is that of how fast do we get to actually execute our code. Are there some things, beyond just leaving a hot JVM active in the background, that can be done to make Truffle pop on startup speeds?

[havenwood]

The Substrate Virtual Machine (SVM) looks promising for TruffleRuby startup speed: https://github.com/graalvm/truffleruby/blob/master/doc/user/svm.md

[ylluminate]

@havenwood it's not crystal, BUT that's super promising! Wow.

[eregon]

See also http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html by @nirvdrum for more details about SVM in the context of TruffleRuby.

I recently found a rather big gain (~1s) on startup of TruffleRuby on JVM, we should re-measure startup.
Further steps could include investigating how to load RubyGems faster as that takes a significant amount of time, even more so on SVM where startup is otherwise around 100ms.

[chrisseaton]

The way that the SubstrateVM works is that you can run the interpreter up until a certain point and then stop execution and freeze the heap at that point for compilation, producing an executable which resumes executing from that point.

This means we have the possibility to go further than for example Crystal, allowing people to load and initialise gems at compile time. We could take a Rails application and create an image from that so that all you do at startup is open the server sockets and start running.

This is a research area though.

[ylluminate]

@chrisseaton SEXY! Lisp and Smalltalk here we come!!!!! This is going to be PERFECT with Docker images. Imagine pre-warmed apps? WOW.

[ch1c0t]

@chrisseaton That's fascinating. I have been wanting something like Smalltalk images for Ruby for a long time.

Could SubstrateVM become open source at some time in the future, or it is unknown at the moment?

[chrisseaton]

I can't say anything about future plans like that, sorry.

[ch1c0t]

Ok, I understand. Sorry for asking.

[wjordan]

Could SubstrateVM become open source at some time in the future, or it is unknown at the moment?

Looks like SubstrateVM indeed became open source under the GPLv2 license, on Dec 12, 2017 (see commit 9fa7c846 in the graalvm/graal project).

[chrisseaton]

Yes, sorry I should have come back here and said this. If you download GraalVM today you can run with --native and get startup time similar to MRI. And it's now open source so you can build with jt build native.