Improvements for modules on Java 9+#5363
Conversation
By moving JRuby into the module path, we are able to silence some of the reflection warnings. This will also be necessary for users that want to expose core JDK classes to JRuby for compatibility purposes. The logic here looks in $JAVA_HOME for the 'jmods' dir, which should be there for all OpenJDK 9+ and not in earlier releases. If that dir is present, we alter the command line in the follwing ways: * If running verified, a la VERIFY_JRUBY=1, all jars including JRuby will be loaded via --module-path instead of -classpath. * If running unverified, a la bootclasspath, the bootclasspath flag is replaced by --module-path, and an additional flag -verify:none is added to blunt the cost of booting. This is not ideal, but all libraries we ship with and all bytecode we generate have been verified many times over in testing. Note that these only affect launching JRuby from the dist release. We will need similar changes to the .cmd launcher and the native jruby-launcher.
|
Ok some thoughts on verification, since I'm reluctant to switch it completely off like this... First, exposure. There's a number of pages that recommend never turning it off, but as we know lots of folks turn it off in development to speed up commands. This change in the I have not researched the likelihood or prior art of exploiting Hotspot with verification off. The main reason this needs to be done is because the bootclasspath flag and the Java module system do not work together, due to boot classes being able to circumvent some aspects of the module system's security guarantees (I believe this is the concern). So if we can't turn verification off and can't use bootclasspath, we have two options I see:
This last option will slow down startup for most users because they have been running with JRuby in bootclasspath (and therefore unverified) previously. For No flags: 3.0-3.2s The JIT results are notable noisy, but overall the verification appears to add from 0.2 to 0.4s to startup. With AppCDS, no verification, --dev: 1.7s So turning verification on may be an acceptable step backwards to help move toward AppCDS use? Note this all comes into play only on Java 9+. Java 8 will continue to work as it does today. |
|
Note that AppCDS for a very large app may only help the first few seconds of startup; code loaded after that will be verified anew. This does not really differ much from today, though, since with bootclasspath we limited the unverified body of code to just what JRuby loaded at boot. |
|
Ok after some discussion, we're going with the following changes. When running on Java 9+ (detected by JAVA_HOME/jmods dir), we will not use the unverified bootclasspath logic in the bash script at all and also make the following tweaks:
This means all Java 9+ will now be fully verified, but in module path. Use AppCDS to eliminate the startup hit of that verification. |
|
Gist comparing Java 8 startup versus Java 11 with and without AppCDS: https://gist.github.com/headius/6228000dcad848c137554496940a9c31 |
1 participant
This PR will track a few small commits to improve how we start up on Java 9+, with a specific eye for running well on Java 11.