There is a special optimization for "only lead parameters"
method dispatch using specialized dispatcher functions
`vm_call_iseq_setup_normal_0start...`.
Other cases (opt, rest, post, ...) we don't use specialized
dispatcher and call with `setup_parameters_complex` to
satisfy Ruby's complex parameter specification.
This commit introduce a specialize dispatcher for
methods which use only lead and optional parameters.
Two step improvements:
(1) prepare "lead/opt" only check pass.
It is to skip the `setup_parameters_complex` function.
(2) introduce specialized dispatcher for only "lead/opt"
parameters methods (vm_call_iseq_setup_normal_opt_start).
With these improvements, we achieved good micro-benchmark
results:
With a method: `def opt2 a, b=nil; end`
With the following binaries:
clean-miniruby: unmodified trunk.
opt_miniruby: apply step (1).
opt_cc_miniruby: apply step (2).
Result with benchmark-driver:
opt2(1)
opt_cc_miniruby: 42269409.1 i/s
opt_miniruby: 36304428.3 i/s - 1.16x slower
clean-miniruby: 25897409.5 i/s - 1.63x slower
opt2(1, 2)
opt_cc_miniruby: 45935145.7 i/s
opt_miniruby: 40513196.9 i/s - 1.13x slower
clean-miniruby: 29976057.6 i/s - 1.53x slower
This improvement may be trivial (difficult to improve practical
cases). However, this is enough small patch so I decide to
introduce it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67315 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* string.c: remove <code> markups, which are not only unnecessary
but also prevented cross-references.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67311 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* string.c (rb_str_crypt): fix indent not to make the whole list
verbatim entirely.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67310 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* parse.y (parser_token_value_print): in ripper, ID values are
wrapped in NODE_RIPPER at set_yylval_name(), so print the Symbol
wrapped together.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67305 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to make it easier to understand what values are grouped.
Just cosmetic changes.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67302 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
by changing interface of `mjit_copy_cache_from_main_thread`.
This is also fixing deadlock introduced by r67299.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67300 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I noticed that r67287 was illegal because memory allocated by `alloca`
was used after the stack is expired.
So I just replaced that with `malloc` and `free` for now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67299 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Take 2 of r67287.
For some reasons, passing pointer of pointer on stack to a function
and assigning an addresse to a pointer dereferenced from the pointer
seems not working on mswin.
So I achieved to return multiple values by returning struct instead of
taking pointers.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67296 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* parse.y (lambda): support numbered parameters, only when no
argument list including empty parentheses, like empty vertical
bars. [ruby-core:91859] [Bug #15672]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67295 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* parse.y (set_yylval_noname): continue after an invalid global,
instance, class variable name, without "unexpected end-of-file"
error.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67292 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This reverts commit 4161674b2f.
Revert "Eliminate mjit_copy_job_t reference from mjit_worker"
This reverts commit d86a1aa045.
Reverting them because of CI failures
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67291 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* parse.y (parser_numbered_param): hoisted out the contextual
check for numbered parameters.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67289 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rather than preparing beforehand.
By having this change, implementing inlining by calling
`mjit_copy_cache_from_main_thread` for inlined methods was made
possible.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67288 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and make `copy_cache_from_main_thread` easier to use.
For implementing inlining later, I'll use `copy_cache_from_main_thread`
inside `mjit_compile`.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67287 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and guard iseq from GC by marking iseq in mjit_copy_job.
This is a refactoring for implementing inlining later and
should not be fixing or introducing any bugs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67286 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to check if it resolves "Permission denied" problem.
https://travis-ci.org/ruby/ruby/jobs/507381339https://travis-ci.org/ruby/ruby/jobs/507392198
TBH I'm not exactly sure why it happens, but I don't have infinite time
to understand this. It would be appreciated to identify the root cause
and remove `DISABLE_CACHE` again if you're sure your patch fixes the problem.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67281 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* --jit-min-calls: 5 -> 10000
--jit-min-calls=5 obviously can compile non hotspot. This was not a
problem for MJIT-benchmarks and Optcarrot because the former has very
few hot optimiziable methods and the latter is likely to trigger
compilation of hotspot by its intensive calls to optimizable hotspot
methods and has a very short window to allow limited compilations.
In real-world applications, it has more time to compile more methods and
it pressures computer's limited resources like icache. We should avoid
compiling too many methods. Also compiling many methods exhausts time
budget for compilation in one ruby process lifetime and delays the "JIT
compaction" of Ruby 2.6.
JVM is known to use 1,500 for C1 (client) compiler and 10,000 for C2
(server) compiler for -XX:CompileThreshold by default.
https://docs.oracle.com/javase/8/embedded/develop-apps-platforms/codecache.htm
When things are called X,000 times, requiring 10,000 can eliminate
compilation of methods which are called only once in these X,000
iterations and obviously not hotspot. And in fact things like
unicorn-worker-killer restarts unicorn process every 4096 requests.
So I felt 10,000 is good for such an environment.
* --jit-max-cache: 1000 -> 100
By the same reason stated above, we should not allow compiling many
methods especially on MJIT which has a larger overhead due to poor code
locality by dlopen and whose code is also likely to be bigger by just
inlining many VM instructions with -O3 rather than directly generating
low-level code.
In JVM -XX:ReservedCodeCacheSize is 32M for reserved and 48M for maximum.
--jit-max-cache=1,000 could be closer to it, but in this case MJIT's
compilation is slow due to data synchronization between threads (to be
improved in Ruby 2.7 though) and we do not want to delay the "JIT
compaction" for a long time.
So I chose a really conservative number for this, but by having method
inlining in the future, wider range could be optimized even with this
value.
* Optcarrot
--disable-gems, --benchmark Lan_Master.nes 12 attempts.
No significant impact.
| r67276 | r67276 --jit | after --jit |
|:-------------------|:------------------|:------------------|
| 50.44369263063978 | 72.87390680773056 | 73.47873485047297 |
| 50.58788746124193 | 78.06820808947026 | 78.29723420171945 |
| 50.77509250801378 | 80.29010348842613 | 78.94689404460769 |
| 50.935361702064405 | 80.42796829926374 | 80.39539527351525 |
| 51.27352672981195 | 81.98758158033202 | 81.6754198664817 |
| 51.720715743242124 | 82.00118535811626 | 82.22960569251283 |
| 51.89643169822524 | 82.2290091613556 | 82.5013636146388 |
| 51.95895898113868 | 82.37318990939565 | 82.74002377794454 |
| 52.10124886807968 | 82.48796686037502 | 83.23354941183932 |
| 52.292280637519376 | 83.0265226541066 | 84.01552618012572 |
| 52.51856237784144 | 83.8797360318052 | 84.8588319093393 |
| 52.65076845986818 | 84.80037351256634 | 85.13577756273656 |
* Railsbench
`WARMUP=20000 BENCHMARK=1000 bin/bench` of https://github.com/k0kubun/railsbench.
It gets closer to --disable=jit.
| | r67276 | r67276 | after |
| | | --jit | --jit |
|:----------|:-------|:-------|:-------|
| req/s | 891.3 | 742.2 | 841.5 |
|:----------|:-------|:-------|:-------|
| 50%ile ms | 1.00 | 1.21 | 1.08 |
| 66%ile ms | 1.02 | 1.24 | 1.09 |
| 75%ile ms | 1.03 | 1.28 | 1.10 |
| 80%ile ms | 1.03 | 1.30 | 1.11 |
| 90%ile ms | 1.09 | 1.42 | 1.15 |
| 95%ile ms | 1.32 | 1.65 | 1.27 |
| 98%ile ms | 4.79 | 2.23 | 1.81 |
| 99%ile ms | 5.68 | 7.52 | 6.64 |
|100%ile ms | 6.52 | 9.69 | 8.59 |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67277 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
ktsj-san recognizes this issue and it's intentionally left failing now.
As failure notification of this task is NOT indicating ruby is broken,
let's stop notifying the failure fo rnow.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67275 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For 2 reasons:
* bundled_gems tend to be left broken (like now)
* We don't want Slack notification for pull request and it can't be
disabled on Azure Pipelines
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67273 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and simplified config by using dedicated webhook URL.
Sadly AppVeyor YAML does not support alias and so we need to copy-paste
the request body.
memo:
https://slack-files2.s3-us-west-2.amazonaws.com/bot_icons/2018-02-10/314363543719_48.png
is the URL used by `provider: Slack`
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67272 b2dd03c8-39d4-4d8f-98ff-823fe69b080e