This is a secret feature for me. It's only for testing and any behavior
with this flag override is unsupported.
I needed this because I sometimes want to add debug options but do not
want to disable optimizations, for using Linux perf.
Now I'm not exactly sure why I needed to check `stop_worker_p` after
`mjit_copy_cache_from_main_thread` of `convert_unit_to_func`
in 4161674b2f.
If it's for avoiding deadlock under `in_gc` condition, we should keep it.
However, if it's not the case and it's just for retrying accidental
compilation failure or just to avoid `MJIT_ATOMIC_SET` and
`compact_all_jit_code`, I think this quick stop path is not mandatory.
Because this path is somewhat problematic in my upcoming fix in
mjit_worker, let me try to remove this first and see how CI goes.
for all compilations and compaction.
Prior to this commit, the last-compiled code has not been used because
MJIT worker is stopped before setting the code, and compaction has also
been skipped.
But it was not intentional and `wait: true` pause should wait until
those two things by its feature.
To fix "gcc: -lgcc: linker input file unused because linking not done" in
https://rubyci.org/logs/rubyci.s3.amazonaws.com/openbsd65/ruby-master/log/20190826T200009Z.log.html.gz
Still I'm intentionally leaving CC_DLDFLAGS_ARGS because making compiler
options different might result in compile/link failure. (Of course
CC_DLDFLAGS_ARGS usually should not have compiler options, but it might
include by bad configure setup)
The same problem may exist in MJIT_LIBS used inside CC_LIBS as well, but
I just ignored that case because it impacts only MinGW / cygwin, hoping
that their users do not perform a wrong configure.
in GC.compact.
While `in_jit` is false, GC.compact is allowed to run and it may be
moving ISeq-related pointers. So calling rb_iseq_path() when `in_jit`
is true is illegal.
I assumed that ISeq is never GC-ed by `in_jit` + `mjit_mark` on copy job
ISeq, but unfortunately I found SEGV on `mjit_copy_job_handler` in which
iseq->body was somehow Qnil. And it seems to be fixed by disabling the
job when `mjit_free_iseq` is called for the ISeq.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67551 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I'm writing `//` comments in newer MJIT code after C99 enablement
(because I write 1-line comments more often than multi-line comments
and `//` requires fewer chars on 1-line) and then they are mixed
with `/* */` now.
For consistency and to avoid the conversion in future changes, let me
finish the rewrite in MJIT-related code.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67533 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Because hard to specify commits related to r67479 only.
So please commit again.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67499 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It seems that `debug_counter_show_results_at_exit` could be called
earlier than `mjit_finish` sometimes.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67380 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
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
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
assuming that -nostartfiles is just optional for mingw, cygwin, and AIX.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66870 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
OpenBSD's GCC compiler has local extensions that break when
`-nostartfiles -nodefaultlibs -nostdlib` is used.
From: Jeremy Evans <merch-redmine@jeremyevans.net>
[Bug #15548]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66869 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
using `-nodefaultlibs -nostdlib`.
I assume libgcc is needed when we use -nostdlib, and it's linked on some
platforms but not linked on some platforms (like aarch64, and possibly
AIX as well) as said in https://wiki.osdev.org/Libgcc :
> You can link with libgcc by passing -lgcc when linking your kernel
with your compiler. You don't need to do this unless you pass the
-nodefaultlibs option (implied by -nostdlib)
Also note that -nostdlib is not strictly needed (rather implied
-nodefaultlibs is problematic for Gentoo like Bug#15513, which will be
approached later) but helpful for performance. So I want to keep it for
now.
[Bug #15522]
I'm not trying to add `-nodefaultlibs -nostdlib` for AIX in this commit
because AIX RubyCI is dead right now, but I'll try to add them again
once RubyCI is fixed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66812 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This should have no impact.
The CC_LIBS was too hard to read for human.
I don't remember whether the order of -lmsvcrt and -lgcc matters or not,
but I kept that for the best safety.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66811 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and functions to clarify the intention and make sure it's not used in a
surprising way (like using 2, 3, ... other than 0, 1 even while it seems
to be a boolean).
This is a retry of r66775. It included some typos...
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66778 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Takashi Kokubun
Yusuke Endoh
tenderlove
k0kubun
nobu
kazu
mame