Running Play on GraalVM

Christian Schmitt, 10 MAY 2018

On the 17th of April, Oracle Labs presented the community the first release cadence for their new universal virtual machine called GraalVM. Graal is a Polyglot VM that can run multiple languages and can interop between them without any overhead. In this blog post I will go into details what this means for Scala and especially for Play Framework and what runtime characteristics the new VM has, when running Play on top of it.

Graal currently comes in two flavors, one is the Community Edition which is open source and comes with the same license as a regular OpenJDK VM. Sadly at the moment the Community Edition is only available for Linux, which is good for production but mostly not enough for everyday development if you are not running Linux on your development machine.

There is also another edition called the Enterprise Edition which is not open source and you need to acquire a license to use it in production, but according to the docs it’s safe to use for development and evaluation. The Enterprise Edition is currently available for macOS and Linux, it has further benefits (comes with a smaller footprint and has more sandbox capabilities).

In the future the Graal team will probably present us with more options regarding the operating system. For our blog post we stick to the Community Edition on Linux.

Play Production Mode

Running Play or any Scala application on Graal is probably as easy as just switching to another Java VM. We will build the Play example project, via sbt-assembly and copy the production JAR to a regular server.

After downloading Graal and unpacking it, one can just run the application via $GRAAL_HOME/bin/java -Xms3G -Xmx3G -XX:+UseG1GC -jar play-scala-starter-example-assembly-1.0-SNAPSHOT.jar. Keep in mind for a production run, one would use a service manager or run the application inside an orchestration system like Kubernetes.

The Play application started without any problem and one could use curl to ensure it is running via curl http://graalserver:9000/ and it will print the Play “hello world page”.

“Performance” of Graal

After having the application running we can check how many requests/s it can serve via Graal, so we start up wrk with the following params: wrk -c100 -d1m -t2 http://graalserver:9000 and get an output like that (after a few runs):

Running 1m test @ http://195.201.117.210:9000
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    33.83ms   62.66ms   1.56s    94.36%
    Req/Sec     2.15k   314.10     3.17k    68.92%
  255800 requests in 1.00m, 1.76GB read
Requests/sec:   4260.50
Transfer/sec:     30.07MB

We can also compare that with a regular JVM which will output the following (after a few runs):

Running 1m test @ http://195.201.117.210:9000
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    38.41ms   70.39ms   1.79s    97.70%
    Req/Sec     1.62k   219.60     3.10k    74.37%
  193123 requests in 1.00m, 1.33GB read
Requests/sec:   3216.56
Transfer/sec:     22.70MB

As we can see Graal will be way faster compared to a regular JVM. The performance boost probably comes from better escape analysis. Keep in mind that the performance will be less on your own tests since you probably won’t run “hello world” on your systems.

AoT compilation

Currently Graal also has a way to compile a Java application to a single binary via native-image. However on Scala 2.12 native-image won’t work since Scala 2.12 relies on the invokedynamic bytecode instruction which as of now is not supported in SubstrateVM. But for reference I tried to use native-image on Scala 2.11.

To make that work I used sbt-assembly to create a standalone JAR that I can use as a reference to my native-image.

Sadly that also won’t work and will fail with the following error:

native-image --no-server -jar target/scala-2.11/play-scala-seed-assembly-1.0-SNAPSHOT.jar
   classlist:  10,847.38 ms
       (cap):   4,676.51 ms
       setup:   5,769.91 ms
warning: unknown locality of class Lplay/api/ApplicationLoader$JavaApplicationLoaderAdapter$1;, assuming class is not local. To remove the warning report an issue to the library or language author. The issue is caused by Lplay/api/ApplicationLoader$JavaApplicationLoaderAdapter$1; which is not following the naming convention.
    analysis:   8,730.53 ms
error: unsupported features in 3 methods
Detailed message:
Error: Must not have a FileDescriptor in the image heap.
Trace:  object java.io.FileOutputStream
        object java.io.BufferedOutputStream

Polyglot

One feature I was excited the most was support for Polyglot, which means that you can run other languages on top of the GraalVM. This is useful for interop with “native” languages or even JavaScript.

Sadly in the current form JavaScript can’t run NodeJS code from a Java Context which means that if I start my program with java my.package.Main and try to call into JavaScript that it can’t run Node. See: https://github.com/graalvm/graaljs/issues/2 for more details on the problem.

But what worked perfectly fine, was calling into native code. In the following example I just try to make a request to example.com via libcurl and print the response code inside my play controller.

For that to work we first need to create a C file:

#include <stdio.h>
#include <curl/curl.h>

long request() {
    CURL *curl = curl_easy_init();
    long response_code = -1;

    if(curl) {
      CURLcode res;
      curl_easy_setopt(curl, CURLOPT_URL, "http://example.com");
      res = curl_easy_perform(curl);
      if(res == CURLE_OK) {
        curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code);
      }
      curl_easy_cleanup(curl);
    }


    return response_code;
}

and turn it into bitcode via: clang -c -O1 -emit-llvm graal.c .

Than we need to add graal-sdk to our build.sbt via:

libraryDependencies += "org.graalvm" % "graal-sdk" % "1.0.0-rc1"

After that we can change one of our Play controllers to invoke it:

private val cpart = {
  val polyglot = Context
      .newBuilder()
      .allowAllAccess(true)
      .option("llvm.libraries", "/usr/lib/libcurl.dylib")
      .build()
  val source = Source
      .newBuilder("llvm", new File("/Users/play/projects/scala/play-scala-seed/graal.bc"))
      .build()
  polyglot.eval(source)
}

def index() = Action { implicit request: Request[AnyContent] =>
  val responseValue = cpart.getMember("request").execute()
  val responseCode = responseValue.asLong()

  Ok(s”$responseCode”)
}

Creating a polyglot Context from Java and calling into another language currently works for the following languages (some which might be more experimental than others): JavaScript, all languages which can be turned into bitcode (C, C++, Rust, etc…), Python 3, R and Ruby.

Conclusion

In most cases Graal will actually run your Play application way faster than a regular JVM. Graal is especially good in running Scala code, since it has a way better escape analysis. However it can depend on your workload and what you do, so it’s probably a good idea to take a look at Graal by yourself.

If you are trying to interop with other languages Graal might also be a really good fit, since most languages can just be executed/run from a simple “Context” and Graal will also try his best to make the code as performant as possible.