That version is strange though, it calls eval during the benchmark!
https://github.com/ruby/ruby/blob/trunk/benchmark/bm_so_fasta.rb does not for instance.

You should confirm this on a newer JRuby and Graal than I am using, but:

$ time ruby2.1 /tmp/bm_so_fasta.rb >/dev/null                              

real    0m1.445s
user    0m1.445s
sys     0m0.000s

$ time JAVACMD=... jruby /tmp/bm_so_fasta.rb  >/dev/null

real    0m3.729s
user    0m8.932s
sys     0m0.128s

$ time JAVACMD=... jruby -X+T -J-server /tmp/bm_so_fasta.rb  >/dev/null

real    0m20.167s
user    0m53.114s
sys     0m0.672s

This is using the version of the benchmark linked above (without eval). The JAVACMD is set to the same JVM each time (the graal internal JDK8).

MRI and JRuby without truffle is faster than JRuby with truffle.

I have a similar benchmark which is essentially the same, but replaces the function with String::scan with a version that uses slicing. Same performance characteristics here too.

I've been playing with this a bit today. I saw similar numbers for MRI 2.3 and JRuby, while JRuby+Truffle was roughly twice (~10s) what @vext01 reported. There's been a lot of changes in our implementation since these numbers were originally reported. In particular, we've completed changed over to a rope-based String representation. There have been changes in Graal, too. So I'm willing to attribute the difference there to the project evolving over the past 7 months.

I've pushed through a couple small changes to optimize some calls. That has brought us to ~7-8s.

Beyond that, I've been trying to break the problem down. The repeat_fasta method doesn't run long enough to compile at all. And that accounts for ~4.5s of the 7-8s I'm seeing. I'll keep investigating and see what I can do for the other two fasta methods.