A clarification: the ascii_only? method does use the code range to return a result, but all it can indicate is whether the "7-bit" bit of the code range is set. It cannot tell us about any of the other bits.

That is probably sufficient for testing the fixed behavior, but I wanted to point out that there's no way to access the raw code range directly despite what this PR claims.

Thanks for the correction.

Do you even want this PR?

Since the bug only appears in compiled code these tests alone don't reproduce anything. Running the test with compile.mode=FORCE can reproduce an error without the fix and it also documents an error without the fix, but curious your thoughts or suggestions on another way to do it as it doesn't replace the other tests right now.

Yes, I think this spec is just fine and the other internal test can be removed since it doesn't actually check the full code range either.

Just to make sure I'm not missing something, my concern is the other test would catch this regressing because it sets sub processes to force compile https://github.com/jruby/jruby/pull/9592/changes#diff-31d52ab943ab646d93c49be70e240a548c99fd4b3c4cbad1d08c36f041292993R18.

Since this one doesn't by default I don't think it would detect a regression. If still your preference though I can update to remove the other tests.

Your agent is basically wrong here. FORCE is only one of the ways we trigger the jit. We have CI runs that set the jit threshold to zero and additional spec runs that execute the specs repeatedly to ensure the jit has finished.

For a bonus you could ask your agent why it believes that mode is necessary and perhaps there's some old documentation it is picking up.

One thing I did realize though: these specs should go under spec/ruby/language since they are directly related to the interpretation and compilation of Ruby code, and not really a test of String behavior.

For reference, this is the spec:ruby:fast:jit target we use in CI. The jit.threshold option is set to zero, which disables background compilation and forces all method and block bodies to be compiled before first execution.

Your agent is basically wrong here. FORCE is only one of the ways we trigger the jit. We have CI runs that set the jit threshold to zero and additional spec runs that execute the specs repeatedly to ensure the jit has finished.

The agent is definitely helpful to me here as there's no way I would have had the time or ability to track down our flaky test, but that question is driven by me (and I guess my agent isn't able to answer it). My goal is to be able to run the test suite and have it fail before the PR and I haven't figured out how to do that. The agent has all kinds of ideas like running in a loop N times, but none of those satisfy me. I couldn't get spec:ruby:fast:jit to work. Let me update this pr to not have the fix PR.

Let me know what doesn't work. If your environment is bootstrapped according to the root docs, it should function ok:

[] jruby $ rake spec:ruby:fast:jit
MSPEC: {compile_mode: "JIT", jit_threshold: 0, format: "d", spec_target: ":fast", command: "ci", jit_max: -1, objectspace_enabled: true, thread_pooling: false, reflection: false, timeout: 120}
rm -rf rubyspec_temp
JAVA options: {dir: "/Users/headius/work/jruby", maxmemory: "1024M", resultproperty: "spec.status.JIT", fork: "true", failonerror: "true", classname: "org.jruby.main.Main"}
$ /Users/headius/work/jruby/bin/jruby -Xbacktrace.style=mri -J-ea -J-Djruby.launch.inproc=false -J-Djruby.compile.mode=JIT -J-Djruby.jit.threshold=0 -J-Djruby.jit.max=-1 -J-Djruby.objectspace.enabled=true -J-Djruby.thread.pool.enabled=false -J-Djruby.reflection=false -J-Demma.coverage.out.file=target/test-results/coverage.emma -J-Demma.coverage.out.merge=true -J-Demma.verbosity.level=silent -J-XX:MaxMetaspaceSize=768M /Users/headius/work/jruby/spec/mspec/bin/mspec-ci -f d --timeout 120 :fast
/Users/headius/work/jruby/spec/mspec/lib/mspec/commands/mspec.rb:110: warning: unsupported exec option: close_others
jruby 10.1.2.0-SNAPSHOT (4.0.0) 2026-08-17 f57d6a5468 OpenJDK 64-Bit Server VM 21.0.8+9-LTS on 21.0.8+9-LTS +indy +jit [arm64-darwin]
/Users/headius/work/jruby/spec/ruby/language/if_spec.rb:143: warning: literal in condition
/Users/headius/work/jruby/spec/ruby/language/method_spec.rb:1239: warning: empty expression
/Users/headius/work/jruby/spec/ruby/language/method_spec.rb:1289: warning: empty expression
/Users/headius/work/jruby/spec/ruby/language/method_spec.rb:1297: warning: empty expression
...etc

You can also run the specs directly, with jit threshold zero, using something like this command line:

$ spec/mspec/bin/mspec ci -T-Xjit.threshold=0 spec/ruby/language/some_spec.rb

I must also mention...in case we haven't discussed this already...

If you are running JRuby in a production setting, I'd love to partner with you to support that use. Fully 100% of my development time is funded through support arrangements from https://headius.com/services. The Expert level means I'm virtually on your team, answering questions and ensure bugs get fixed and released, but if every JRuby user in the world signed up for the basic Professional level, we'd be fully funded.

Partnering in this way also helps JRuby improve based on your needs. I can't guess what to prioritize for real-world JRuby apps unless I know about those apps. It's a win for both of us.

Please consider partnering with us to keep JRuby healthy and moving forward!

Let me know what doesn't work.

It doesn't seem to work. Let me know if I am totally missing something here. I believe jwils@6449e75 fixes it, but surfaces some other failed tests. Let me know if you think that fix looks correct. I can attempt to make that first and see what other work is needed to get the test suite to pass.

If you are running JRuby in a production setting, I'd love to partner with you to support that use.

I wasn't aware of this, our JRuby usage is limited, but we've recently added JRuby to elasticgraph (one of our opensource projects). I'll look into support partnerships internally

The agent may be right about JRUBY_OPTS not getting passed through from the original command-line rake call. I do see where the rake tasks set up a new JRUBY_OPTS env var, without including anything passed in.

Honestly I'm unsure if this is wrong. If you have a JRUBY_OPTS environment that tweaks JIT settings, you may not want the rake target you call to behave differently. It is a valid concern that our non-indy jobs may not be running without indy, but I'll look into that separately now that I see it might be a problem.

At the very least we do have jobs eagerly running the JIT, which is the key requirement for this PR.

FWIW it does look like the other suites avoid clobbering JRUBY_OPTS if they need to add something:

I'm going to contemplate whether there might be a cleaner way to allow both runtime configuration from the rake command line AND pre-defined targets with specific configs.

I've opened #9597 to track improvements to how we tweak the runtime configuration for rake targets.