Environment

• JRuby: jruby 9.1.15.0 (2.3.3) 2017-12-07 929fde8 Java HotSpot(TM) 64-Bit Server VM 25.151-b12 on 1.8.0_151-b12 [linux-x86_64]
• Kernel: Linux u186024434db159d25c92 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Distro: Ubuntu 16.04.3 LTS

Expected Behavior

With frozen_string_literal enabled, always MRI reuses repeated copies of the same literal.

Testcase:

# frozen_string_literal: true

puts RUBY_DESCRIPTION

DUMMY_VALUE = 'hello bug'
puts "object_id for DUMMY_VALUE: #{DUMMY_VALUE.object_id}"

Integer(ENV['THREADS'] || 100).times do
  Thread.new { }
end

OTHER_VALUE = 'hello bug'
puts "object_id for OTHER_VALUE: #{OTHER_VALUE.object_id}"

Output on MRI:

$ ruby spec/helpers/dummy_thread.rb
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
object_id for DUMMY_VALUE: 10642320
object_id for OTHER_VALUE: 10642320

Actual Behavior

JRuby's behavior for this is pretty bizarre. With THREADS set to a small number, it works the same as MRI:

$ THREADS=10 ruby --dev spec/helpers/dummy_thread.rb
jruby 9.1.15.0 (2.3.3) 2017-12-07 929fde8 Java HotSpot(TM) 64-Bit Server VM 25.151-b12 on 1.8.0_151-b12 [linux-x86_64]
object_id for DUMMY_VALUE: 2000
object_id for OTHER_VALUE: 2000

But eventually as you raise the number of threads, it stops reusing the literal:

$ THREADS=100 ruby --dev spec/helpers/dummy_thread.rb
jruby 9.1.15.0 (2.3.3) 2017-12-07 929fde8 Java HotSpot(TM) 64-Bit Server VM 25.151-b12 on 1.8.0_151-b12 [linux-x86_64]
object_id for DUMMY_VALUE: 2000
object_id for OTHER_VALUE: 2002

The example above is from a test suite that was randomly failing on JRuby sometimes, as it randomly ordered threads and thus it would fail when the tests that played with threads ran before a test that tested that two literals were exactly the same.