Ruby

Yes, I recognize this problem and will investigate the cause for sure. I don't know a clear cause for this yet.

I suspect this is happening cause we are introducing new overhead to every single method dispatch (counting for mjit, and hash lookup and so on). This overhead adds up.

My understanding of new overheads: JIT enqueue on 5 total calls, total calls count up (sometimes it happens twice for now), JIT-ed C function call instead continueing in the same VM, and additional VM invocation for not JIT-ed methods or JIT cancel. Some of those overheads might grow in Rails. I need investigation.

I'm not sure what's hash lookup.

Applied in changeset trunk|r64094.

mjit.c: introduce JIT compaction [experimental]

When all compilation finishes or the number of JIT-ed code reaches
--jit-max-cache, this compacts all generated code to a single .so file
and re-loads all methods from it.

In the future, it may trigger compaction more frequently and/or limit
the maximum times of compaction to prevent unlimited memory usage.
So the current behavior is experimental, but at least the performance
improvement in this commit won't be removed.

=== Benchmark ===
In this benchmark, I'll compare following four conditions:

• trunk: r64082
• trunk JIT: r64082 w/ --jit
• single-so JIT: This commit w/ --jit
• objfcn JIT: This branch https://github.com/k0kubun/ruby/tree/objfcn w/ --jit,
  which is shinh's objfcn https://github.com/shinh/ruby/tree/objfcn rebased from this commit

$ uname -a
Linux bionic 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

• Micro benchmark
  Using this script https://gist.github.com/k0kubun/10e6d3387c9ab1b134622b2c9d76ef51,
  calls some amount of different methods that just return nil. The following tables
  are its average duration seconds of 3 measurements.

Smaller is better.

** 1 method (seconds)

** 50 methods (seconds)

** 1500 methods (seconds)

• Discourse
  Using the same benchmark strategy as https://bugs.ruby-lang.org/issues/14490 with
  this branch https://github.com/k0kubun/discourse/commits/benchmark2 forked from discourse
  v1.8.11 to support running trunk.

1. Run ruby script/bench.rb to warm up profiling database
2. Run RUBYOPT='--jit-verbose=1 --jit-max-cache=10000' RAILS_ENV=profile bin/puma -e production
3. WAIT 5-15 or so minutes for all jitting to stop so we have no cross talk
4. Run ab -n 100 http://localhost:9292/
5. Wait for all new jitting to finish
6. Run ab -n 100 http://localhost:9292/

** Response time (ms)
Here is the response time milliseconds for each percentile.
Skipping 99%ile because it's the same as 100%ile in 100 calls.

| | trunk| trunk|single|objfcn|

** Ratio (smaller is better)
Here is the response time increase ratio against no-JIT trunk's one.

| | trunk| trunk|single|objfcn|

While 50 and 60 %ile are still worse than no-JIT trunk, 75, 80, 90, 95,
98 and 100% are not slower than that.

So now it's a little harder to say "MJIT slows down Rails applications".
Probably I can close [Bug #14490] now. Let's start improving it.

Close https://github.com/ruby/ruby/pull/1921