Open JaroslavTulach opened 7 months ago
Few points from a discussion during morning standup on Monday Feb 26:
Standard.Base
with Native Image?
--jvm
switch which could mitigate the problem with --jvm
the startup would be slower (as no isolates would be used), but the peak performance would be as fast as nowThe latest OracleLabs GraalVM meetup introduced a concept of Crema project. If Crema flies, it will allow interop between libraries compiled by native image and those interpreted by Crema. Let's put the isolates work on hold for now.
Oracle GraalVM (e.g. not the community edition, but the paid version) offers concept of isolates. Polyglot Isolates allow one to use natively compiled languages from a JVM. Such a setup would be ideal for Enso - our language could be natively compiled and our libraries could run in regular (e.g. HotSpot like) JVM.
33% Speed up
I've just finished measurements and got everything running. Simple
IO.println "Hello world"
application which starts in 3s or more currently (see the Startup_hello_world_startup benchmark). With the polyglot isolates the same code starts in 2s:E.g. we gain 33% speedup, if we repackage Enso to use isolates. Moreover we don't pay the price of using experimental Espresso as previous attempts like #8641 tried. Isolates seem to be fully compatible and fully supported by Oracle (in its commercial version of GraalVM).
Reproducer
Get the changes in PolyglotIsolates branch. Get (build 21.0.2+13-LTS-jvmci-23.1-b30) Java HotSpot(TM) 64-Bit Server VM and execute:
The regular version of Enso has just been built and can be tested. Use:
Then continue to building the isolates. Copy additional
truffle-enterprise
support and its dependencies into thebuilt-distribution
directory and buildrunner.so
shared library:with built
runner.so
we can use Enso with the isolates. The simplest way is:but that also includes compilation of
Enso.java
to Java bytecode. To avoid that compile the.java
file infront of the execution. Then the time goes to 2s: