Exclude certain engine methods from Tier 4 compilation

[niloc132]

This commit excludes ~11 methods from hotspot's Tier 4 (aka C2) JIT compilation. Each of these has been found crash the certain JVM implementations (across vendors, across OSes, and across hardware archetectures) when it compiles this code, but not consistently. By excluding only C2 in this way, we allow C1 (aka Tier 1-3) to still run, and get better performance than interpreted bytecode.

All existing ways to run code should be affected by this - running main()s or tests through either gradle or IntelliJ, and running our shell scripts to launch the server will all end up with a compiler directives file to disable c2 for these methods. Using the engine as a library is not fixed in this way, but this is a problem that can only be solved through documentation, to inform users that they should make sure to start the JVM with a specific set of flags.

An extra array of "devJvmArgs" is left in the io.deephaven.java-conventions plugin to make it easier to add more flags later for this kind of problem - it will automatically be included for all of the above categories.

Fixes #1529

[niloc132]

Tested in Java11 and 17, see https://github.com/deephaven/deephaven-core/runs/5205478306?check_suite_focus=true - I will keep re-running this to ensure that 17 doesn't run into surprise issues. I'll put up a later PR to introduce the changes that lead to that nightly build as well.

We might want to consider the c2-excludes.txt as a build output, or at least publish its contents with each release. It might also make sense to rename it, as we might refine this e.g. to also disable inlining if we find that a specific method is the actual problem, etc.

[devinrsmith]

On the unix version, you had -XX:+UnlockDiagnosticVMOptions - is that not needed here?

[niloc132]

I'll need to double check, I moved it a few times in my hopes of parameterize this file. I'll test on windows with Don tomorrow.

[niloc132]

It turns out that start.bat doesn't run anyway on Win10 from main, so changing it at this time might be a mistake.

C:\....path\to\deephaven-core\server\jetty\build\install\server-jetty\bin\start.bat
The input line is too long.
The syntax of the command is incorrect.

[devinrsmith]

Maybe interesting in the future to examine - mvn is distributed w/ an application layout that looks like:

drwxr-xr-x.  2 devin devin   160 Jun 17  2018 bin
drwxr-xr-x.  2 devin devin    60 Jun 17  2018 boot
drwxr-xr-x.  3 devin devin   100 Jun 17  2018 conf
drwxr-xr-x.  4 devin devin  1660 Jun 17  2018 lib
-rw-r--r--.  1 devin devin 20965 Jun 17  2018 LICENSE
-rw-r--r--.  1 devin devin   182 Jun 17  2018 NOTICE
-rw-r--r--.  1 devin devin  2530 Jun 17  2018 README.txt

I like the name conf, if we wanted to put compiler directives there eventually.

The boot is also interesting; it is a launcher api https://codehaus-plexus.github.io/plexus-classworlds/launcher.html that allows for "easier" application classpath configuration:

$ cat bin/m2.conf 
main is org.apache.maven.cli.MavenCli from plexus.core

set maven.conf default ${maven.home}/conf

[plexus.core]
load       ${maven.conf}/logging
optionally ${maven.home}/lib/ext/*.jar
load       ${maven.home}/lib/*.jar

Given our issues with long CLI arguments (on Windows), I wonder if we should try to craft our shell launchers to use star on the lib directory, instead of trying to list them all out?

[niloc132]

Given our issues with long CLI arguments (on Windows), I wonder if we should try to craft our shell launchers to use star on the lib directory, instead of trying to list them all out?

Downside of star is relying on the order that the shell uses, instead of deterministic classpath order from the specified list of jars.

[devinrsmith]

Given our issues with long CLI arguments (on Windows), I wonder if we should try to craft our shell launchers to use star on the lib directory, instead of trying to list them all out?

Downside of star is relying on the order that the shell uses, instead of deterministic classpath order from the specified list of jars.

I don't think it actually relies on shell-globbing - I think that java is able to accept arguments and expand the star itself. But, this is a concern potentially for later on.