after the first compilation on --jit-wait.
Previously the assignment to `func` didn't have meaning for the behavior,
and the compiled code wasn't called immediately after the synchronous
compilation. It wasn't intentional.
Fixing this issue without impacting performance without --jit-wait is
not so obvious. Adding branch or goto to call func in mjit_exec spoiled
the performance without --jit-wait. Instead of that, I called the func
inside mjit_wait_call() (former mjit_get_iseq_func()) which is never
inlined to mjit_exec(). Thanks to that, this commit has no impact for
normal performance.
mjit.c: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64929 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
of mjit_worker(). It was needed when mjit_worker.c is separated from
mjit.c, but it's now just included.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64306 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
instead of linking functions with mjit_worker.o.
In the r64285's structure, we needed to publish some variables with
mjit_ prefix. But ideally those variables should be completely private
in mjit.o (or old mjit_worker.o), and it was hard.
So I chose an approach similar to vm*.c for mjit.c and mjit_worker.c.
I believe mjit_compile.c is still nice to be separated.
After this commit, I'll remove the mjit_ prefix again...
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64289 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
from mjit.c because it's executed only on MJIT worker thread.
Instead of that, `valid_class_serials` is shared with mjit_ prefix.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64288 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
which was just forgotten.
mjit.c: ditto
mjit_internal.h: moved some macros only used by mjit_worker.c to it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64287 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The motivation of this change is to make sure rb_funcall or GC-related
functions are not called on worker-related code. Currently such
functions are used in some places and I believe it's partly because it's
hard to identify which part is called on MJIT worker thread.
Now, mjit.c is safe to use them but we know we need to safely deal with
mjit_compile.c, mjit_worker.c and mjit_internal.h.
mjit_compile.c: update the comment about it
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64285 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* version.c (Init_ruby_description): separate to initialize
RUBY_DESCRIPTION constant according to mjit.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64264 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
by sharing it with vm.c in internal.h.
vm.c: ditto
internal.h: ditto
mjit.h: share more.
mjit.c: make sure the third arguemnt is not used
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64253 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and wait until JIT queue is flushed when wait option is not passed or
`wait: true` is passed.
vm.c: ditto
test/ruby/test_rubyvm_mjit.rb: added test for pause/resume
test/lib/jit_support.rb: allow retrying MJIT on JITSupport level
test/ruby/test_jit.rb: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64250 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
[Bug #14867] implemented exactly what was needed (for POSIX
platforms, at least).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64225 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
By this commit's changes in other files, now MJIT started to work on VC++.
Unfortunately some features are still broken and they'll be fixed later.
This also suppresses cl.exe's default output to stdout because there
seems to be no option to do it. Tweaking some log messages as well.
vm_core.h: declare `__declspec(dllimport)` to export them correctly on mswin.
vm_insnhelper.h: ditto
mjit.h: ditto
test_jit.rb: skipped some pending tests.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64221 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This option makes sure that the argument is C source file.
Probably this is not needed, but since I'm debugging it, I want to
exclude any failure possibility for now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64196 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This is needed to resolve:
"error LNK2011: precompiled object not linked in; image may not run"
win32/Makefile.sub: Use the same flags as ones for precompiled header.
This is needed to resolve:
"error C2855: command-line option '/Z7' inconsistent with precompiled header"
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64192 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
on mswin properly.
Deleted code to attempt make_pch for mswin, since it won't be needed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64190 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
file name correctly. This allows to use the header installed by r64188.
win32/Makefile.sub: define prebuilt precompiled header path instead of
unused min header path
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64189 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
because linking multiple .o files is problematic without having `static`
to the same function definitions.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64162 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
is specified.
This is needed for MinGW because MJIT_BUILD_DIR doesn't prefix path
like "C:\msys64", so it can't be read without msys2's conversion.
The workaround is not needed for Windows (LOAD_RELATIVE looks defined by
default) anyway. So removed it for such environment.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64161 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
on MinGW with __atomic_exchange_n(). It returns the previous pointer value but
obviously it's not needed in MJIT's usage.
mjit.c: In function 'compact_all_jit_code':
ruby_atomic.h:11:36: warning: value computed is not used [-Wunused-value]
# define ATOMIC_EXCHANGE(var, val) __atomic_exchange_n(&(var), (val), __ATOMIC_SEQ_CST)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64160 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This macro shall be shared among other files, not just for mjit.c.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64156 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
when $MJIT_SEARCH_BUILD_DIR is set.
If prefix path is owned by root, `make install` needs to be run by root.
But in general we don't want to run `make test-all`, and also running
`make test-all` currently fails due to permission tests of rdoc and rubygems.
Thus, prior to this commit, specifying a prefix like "/usr/local" could
mean there was no way to pass test-all.
So we should not depend on `make install` for `make test-all`. Thus I
reverted r64104 and r64103, and applied this workaround to pass `make
test-all` without `make install`.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64143 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We see several occurrence of "diagnostic push/pop" so why not
make them macros. Tested on GCC8 / Clang 6.
Note that ruby.h is intentionally left untouched because we don't
want to introduce new public macros.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64118 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to use compaction with --jit-save-temps.
Prior to this commit, JIT compaction didn't work with --jit-save-temps
but it wasn't intentional.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64100 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
When --jit-wait is specified, `unit_queue.length` is always 0 and it's
not a good metric.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64097 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
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)
| | trunk | trunk JIT | single-so JIT | objfcn JIT |
|:------|:------------------|:------------------|:------------------|:------------------|
| Time | 5.576067774333296 | 5.915551971666446 | 5.833641665666619 | 5.845915191666639 |
| Ratio | 1.00x | 1.06x | 1.05x | 1.05x |
** 50 methods (seconds)
| | trunk | trunk JIT | single-so JIT | objfcn JIT |
|:------|:------------------|:------------------|:------------------|:------------------|
| Time | 3.1661167996666677| 6.125825928333342 | 4.135432743666665 | 3.750358728333348 |
| Ratio | 1.00x | 1.93x | 1.31x | 1.18x |
** 1500 methods (seconds)
| | trunk | trunk JIT | single-so JIT | objfcn JIT |
|:------|:------------------|:------------------|:------------------|:------------------|
| Time | 5.971650823666664 | 19.579182102999994| 10.511108153999961| 10.854653588999932|
| Ratio | 1.00x | 3.28x | 1.76x | 1.82x |
* 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|
| | | JIT|so JIT| JIT|
|:----|:-----|:-----|:-----|:-----|
| 50% | 38 | 45 | 41 | 43 |
| 66% | 39 | 50 | 44 | 44 |
| 75% | 47 | 51 | 46 | 45 |
| 80% | 49 | 52 | 47 | 47 |
| 90% | 50 | 63 | 50 | 52 |
| 95% | 60 | 79 | 52 | 55 |
| 98% | 91 | 114 | 91 | 91 |
|100% | 97 | 133 | 96 | 99 |
** Ratio (smaller is better)
Here is the response time increase ratio against no-JIT trunk's one.
| | trunk| trunk|single|objfcn|
| | | JIT|so JIT| JIT|
|:----|:-----|:-----|:-----|:-----|
| 50% | 1.00x| 1.18x| 1.08x| 1.13x|
| 66% | 1.00x| 1.28x| 1.13x| 1.13x|
| 75% | 1.00x| 1.09x| 0.98x| 0.96x|
| 80% | 1.00x| 1.06x| 0.96x| 0.96x|
| 90% | 1.00x| 1.26x| 1.00x| 1.04x|
| 95% | 1.00x| 1.32x| 0.87x| 0.92x|
| 98% | 1.00x| 1.25x| 1.00x| 1.00x|
|100% | 1.00x| 1.37x| 0.99x| 1.02x|
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
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64094 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and lazily delete them on termination.
This will be needed to create a large so file later.
The large number of .o files will be probably compacted before the large so
file is created.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64077 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
units, renaming it from NOT_COMPILABLE_JIT_ISEQ_FUNC.
NOT_READY_JIT_ISEQ_FUNC is for ones being compiled, so
mjit_get_iseq_func treats it specially and it shouldn't be used for the
purpose.
I renamed it instead of adding a new one because I'm not sure about the
impact for the performance by increasing the switch branches in mjit_exec.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64076 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
by whether on mswin or not.
This is needed because I'm going to renew the compilation process for
unix, keeping mswin builds as it is, at first.
This commit is not changing the behavior at all.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64051 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
which was missing in r64033.
Prior to r64033, memory allocation failure had been checked by
TRY_WITH_GC and handled by rb_memerror. But calling rb_memerror on MJIT
worker is problematic since it does EC_JUMP_TAG in the end. Threads
except Ruby's main thread must not use it.
mjit_compile.c: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64037 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
mjit_compile.c: ditto.
REALLOC_N, ALLOC_N and xmalloc trigger GC but it's not expected.
Other allocation calls in mjit.c are executed on Ruby's main thread and
thus fine.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64033 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
pthread_atfork is not idempotent and repeatedly calling it
causes it to register the same hook repeatedly; leading to
unbound memory growth.
Ruby already has a (confusing-named) internal API for to call
in the forked child process: rb_thread_atfork
Call the MJIT child_after_fork hook inside that to prevent
unbound growth with the following loop:
loop do
RubyVM::MJIT.pause
RubyVM::MJIT.resume
end
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63884 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We started checking return value of waitpid, so it needs
to be correct for win32 platforms for MJIT to work.
Thanks-to: MSP-Greg (Greg L) <Greg.mpls@gmail.com>
[ruby-core:87832] [Bug #14867]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63869 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
k0kubun
nobu
normal
shyouhei