http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1480173
It tries to print C backtrace but fails. And core file on the server
seems to be stopping on the irrelevant place due to its own signal
handler for the dump.
And I failed to reproduce this SEGV on my machine.
I don't know why it's broken, so let me try this change to investigate
the reason of SEGV.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65997 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
it didn't work.
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1468677
and skips broken tests for now. But this issue should be fixed soon.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65814 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to prevent from proceeding one for MJIT while it's not safe yet.
By that situation, MJIT worker could be waiting for compiler process forever
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1468033
[Bug #15320]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65807 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
by launching MJIT worker thread in child Ruby process.
See the comment before `mjit_child_after_fork` for details.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65785 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Makefile.in (mjit_build_dir.so): separate MJIT_BUILD_DIR to
eliminate the feature for test-all after installation.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65587 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
-available region. reducing risk of SEGV in mjit_copy_job_handler() like
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1446117
I'm not sure which exact part is causing "[BUG] Segmentation fault at 0x0000000000000008"
on `(mjit_copy_job_handler+0x12) [0x564a6c4ce632] /home/ko1/ruby/src/trunk-mjit/mjit.c:26`...
mjit.c: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65569 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* Makefile.in (mjit_build_dir.so): separate MJIT_BUILD_DIR to
eliminate the feature for test-all after installation.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65563 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* mjit.c (init_header_filename): sticky-mode directory probably
would be less unsafe even if it is not owned.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65551 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rb_mjit_unit can either exist in unit_queue or active_units, but
not both. This will make state transitions for event-based MJIT
process management easier.
v2: recheck unit->iseq after GC wakeup
The iseq may be GC-ed while we were waiting for it since we
delete the unit from unit_queue during get_from_list
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65475 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
https://bugs.ruby-lang.org/issues/14867#note-112
I wanna touch similar places. To avoid our conflict, let me merge Eric's patch earlier.
Let's watch trunk-mjit / trunk-mjit-wait CIs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65473 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rb_mjit_unit can either exist in unit_queue or active_units, but
not both. This will make state transitions for event-based MJIT
process management easier.
[ruby-core:89654]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65468 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For robustness against future changes. There should be no impact
at the moment,here, but we may call mjit_finish more than once
in a process lifetime in the future (implementing "stop"
instead of just "pause")
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65443 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Given that `copy_cache_from_main_thread()` breaks the loop when `stop_worker_p`
is TRUE, memory of `job` allocated by `alloca` may be invalid if `stop_worker_p`
is already TRUE.
mjit_worker.c: explain why `copy_cache_from_main_thread()` should not
stop checking `stop_worker_p`.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65312 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
on VM_CHECK_INTS. Letting MJIT worker directly see inline cache which
may be being updated could result in inconsistent IC index and serial.
mjit_worker.c: request the copy job after dequeue, and receive the
result synchronously.
tool/ruby_vm/views/_mjit_compile_ivar.erb: use the copied IC
mjit_compile.c: change the interface to pass is_entries
mjit.h: ditto
=== Optcarrot Benchmark ===
Thankfully this didn't have major performance regression.
$ benchmark-driver benchmark.yml --rbenv 'before::before --disable-gems --jit;after::after --disable-gems --jit' -v --repeat-count 24
before: ruby 2.6.0dev (2018-10-21 trunk 65263) +JIT [x86_64-linux]
after: ruby 2.6.0dev (2018-10-21 trunk 65263) +JIT [x86_64-linux]
last_commit=mjit.c: copy inline cache values to MJIT worker
Calculating -------------------------------------
before after
Optcarrot Lan_Master.nes 85.421 85.454 fps
Comparison:
Optcarrot Lan_Master.nes
after: 85.5 fps
before: 85.4 fps - 1.00x slower
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65275 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* configure.ac: introduce new configure option `--enable-mjit` and
`--disable-mjit`. Default is "enable".
`--disable-mjit` disables all of MJIT features so that `ruby --jit`
can't enable MJIT.
This option affect a macro `USE_MJIT`.
This change remove `--enable/disable-install-mjit-header` option.
* Makefile.in: introduce the `ENABLE_MJIT` variable.
* common.mk: use `ENABLE_MJIT` option.
* internal.h: respect `USE_MJIT`. Same as other *.c, *.h.
* test/ruby/test_jit.rb: check `ENABLE_MJIT` key of rbconfg.rb.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65204 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
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
k0kubun
kazu
nobu
normal
ko1