Discovered by an agent in #9596...
Currently we have a few spec runs that are intended to execute with invokedynamic optimizations turned off. They do this by setting the JRUBY_OPTS environment variable before running rake, adding flags like -Xcompile.invokedynamic=false.
However, because some of the rake tasks in question build their own JRUBY_OPTS environment variables, the value set at the command line gets clobbered. As a result the CI jobs are not actually disabling invokedynamic.
I believe we want the specific tasks like spec:ruby:fast:jit to always run the same way, but I recognize we need a better way to add more options (and clearly when we have a job that's supposed to run without indy, it should run without indy). Permuting every runtime config option is clearly not feasible.
Passing arguments to the tasks may be the best way, and I'm researching to figure out what is standard these days for doing so. If we had a single configurable task that took multiple runtime arguments, it could be called like
rake spec:ruby:fast[jit = true, threshold = 0, indy = false]
while still keeping some easy short-cut targets in place.
Discovered by an agent in #9596...
Currently we have a few spec runs that are intended to execute with invokedynamic optimizations turned off. They do this by setting the
JRUBY_OPTSenvironment variable before running rake, adding flags like-Xcompile.invokedynamic=false.However, because some of the rake tasks in question build their own
JRUBY_OPTSenvironment variables, the value set at the command line gets clobbered. As a result the CI jobs are not actually disabling invokedynamic.I believe we want the specific tasks like
spec:ruby:fast:jitto always run the same way, but I recognize we need a better way to add more options (and clearly when we have a job that's supposed to run without indy, it should run without indy). Permuting every runtime config option is clearly not feasible.Passing arguments to the tasks may be the best way, and I'm researching to figure out what is standard these days for doing so. If we had a single configurable task that took multiple runtime arguments, it could be called like
rake spec:ruby:fast[jit = true, threshold = 0, indy = false]while still keeping some easy short-cut targets in place.