Graal: Startup of application via GraalVM-CE-1.0-rc15 is a bit slower than the traditional JDK8 version

Created on 8 Apr 2019  路  13Comments  路  Source: oracle/graal

This might be application specific, and not necessary happening for all applications

I'd like to know if there are _any flags to pass on the CLI as args to speed up the startup_? Maybe it is expected to startup slow but would love to know what is happening and why. Are there any _CLI args to enable logging/recording of diagnostics_ when running with the Graal compiler enabled?

If I have to diagnose this myself what should I be _enabling and also looking at_ in the logs?

Either way these diagnostics will help both myself and your team.

bug compiler

Most helpful comment

We identified the issue and are working on a fix. It is related to "shutdown hooks" that prevent the VM process from exiting when a compilation is currently running. Thanks for the report.

All 13 comments

There is a slight chance that this issue might be similar to https://github.com/oracle/graal/issues/1140.

The app in question can be found at https://github.com/neomatrix369/awesome-ai-ml-dl/tree/master/examples/data/databases/graph/grakn, all the instructions to start the container (option for GraalVM is also provided) is present in the README, you will see the console logs show how much time it took to start the app.

We identified the issue and are working on a fix. It is related to "shutdown hooks" that prevent the VM process from exiting when a compilation is currently running. Thanks for the report.

We identified the issue and are working on a fix. It is related to "shutdown hooks" that prevent the VM process from exiting when a compilation is currently running. Thanks for the report.

Thanks for the response, I'll await the fix. In the meanwhile is it worth using the below flag:

 -XX:-UseJVMCINativeLibrary

Can I also use this with the JAVA_OPTS environment variable:

JAVA_OPTS="-XX:-UseJVMCINativeLibrary ${JAVA_OPTS}"

I would also suggest adding regression test(s) to capture startup time (covering multiple scenarios, if needed) so that it gets flagged (if it regresses in functionality) during your nightly builds at least. You are able to catch such issues way before they make it into the wild or into the next RC.

Wrt to using -XX:-UseJVMCINativeLibrary, it depends on your use case.

Your advise for regression tests is spot on - we will add some.

BTW, in case you are interested, this is the fix being proposed so far: https://github.com/dougxc/graal-jvmci-8/commit/d8d8e27d21066f266df4149f037a5cde334a004d

Wrt to using -XX:-UseJVMCINativeLibrary, it depends on your use case.

Your advise for regression tests is spot on - we will add some.

BTW, in case you are interested, this is the fix being proposed so far: dougxc/graal-jvmci-8@d8d8e27

Happy to take a look at the regression suite when it's ready. Do all the tests now reside in this repo or is there a separate one for it? I'll try to play around with them to see if I can find anything else that might help.

We have tests in various places but a lot of them are in this repo.

Adding a regression test for this aspect is difficult due to the variability in results when measuring warmup. It is possible to detect large regressions, but almost impossible to detect very small ones.

Adding a regression test for this aspect is difficult due to the variability in results when measuring warmup. It is possible to detect large regressions, but almost impossible to detect very small ones.

Makes sense, I can see how it can be a needle in a haystack issue. How about adding the tests that can be used to catch most of the issues and leaving the less practical ones to be reported by users like us, using #graal in the wild!

Have you tried running mx gate? That will run all the tests we have in this repo.

Have you tried running mx gate? That will run all the tests we have in this repo.

Thanks, you read my mind. I was going to ask how to. I used the command:

mx unittests

or

mx tests

In the past, but they don't run the whole thing I guess. I'll check this out.

There is an mx coverage as well or something to see test coverage - is this worth looking at, and does it give a good picture of the tests covered?

Running mx gate --jacocout html should result in a coverage report being generated in a html/ subdirectory.

Re-ran the above with RC15 and compared it with the traditional JDK8, there is a small ~6 seconds startup lag with RC15, see https://github.com/neomatrix369/awesome-ai-ml-dl/blob/master/examples/data/databases/graph/grakn/successful-run-console.md

I'll close this issue for now, since it has been addressed. I will try to use native images and also run a detailed performance suite on the app itself to see if there are run-time differences.

Re-ran the above with RC15 and compared it with the traditional JDK8, there is a small ~6 seconds startup lag with RC15, see https://github.com/neomatrix369/awesome-ai-ml-dl/blob/master/examples/data/databases/graph/grakn/successful-run-console.md

I'll close this issue for now, since it has been addressed. I will try to use native images and also run a detailed performance suite on the app itself to see if there are run-time differences.

Just to let you know the startup time has improved since I last reported, see current status at https://github.com/neomatrix369/awesome-ai-ml-dl/blob/master/examples/data/databases/graph/grakn/successful-run-console.md

Good work #graal team!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sebthom picture sebthom  路  3Comments

jinwuxia picture jinwuxia  路  3Comments

borkdude picture borkdude  路  3Comments

guaporocco picture guaporocco  路  3Comments

koduki picture koduki  路  3Comments