* include/ruby/ruby.h (rb_uint2big, rb_int2big): declare with
uintptr_t and intptr_t instead of VALUE and SIGNED_VALUE
respectively. [ruby-core:83424] [Bug #14036]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62494 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
tool/ruby_vm/views/_insn_name_info.erb: on Linux, rb_vm_insn_name_offset
was needed to compile with --jit-debug (Usually --jit-debug requires
more symbols than the situation without --jit-debug because -O2 skips
some functions to compile).
vm.c: when running transform_mjit_header.rb with --jit-wait,
rb_source_location_cstr was repoted to be missing.
string.c: ditto, for rb_str_eql
numeric.c: ditto, for rb_float_eql
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62313 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
which has been developed by Takashi Kokubun <takashikkbn@gmail> as
YARV-MJIT. Many of its bugs are fixed by wanabe <s.wanabe@gmail.com>.
This JIT compiler is designed to be a safe migration path to introduce
JIT compiler to MRI. So this commit does not include any bytecode
changes or dynamic instruction modifications, which are done in original
MJIT.
This commit even strips off some aggressive optimizations from
YARV-MJIT, and thus it's slower than YARV-MJIT too. But it's still
fairly faster than Ruby 2.5 in some benchmarks (attached below).
Note that this JIT compiler passes `make test`, `make test-all`, `make
test-spec` without JIT, and even with JIT. Not only it's perfectly safe
with JIT disabled because it does not replace VM instructions unlike
MJIT, but also with JIT enabled it stably runs Ruby applications
including Rails applications.
I'm expecting this version as just "initial" JIT compiler. I have many
optimization ideas which are skipped for initial merging, and you may
easily replace this JIT compiler with a faster one by just replacing
mjit_compile.c. `mjit_compile` interface is designed for the purpose.
common.mk: update dependencies for mjit_compile.c.
internal.h: declare `rb_vm_insn_addr2insn` for MJIT.
vm.c: exclude some definitions if `-DMJIT_HEADER` is provided to
compiler. This avoids to include some functions which take a long time
to compile, e.g. vm_exec_core. Some of the purpose is achieved in
transform_mjit_header.rb (see `IGNORED_FUNCTIONS`) but others are
manually resolved for now. Load mjit_helper.h for MJIT header.
mjit_helper.h: New. This is a file used only by JIT-ed code. I'll
refactor `mjit_call_cfunc` later.
vm_eval.c: add some #ifdef switches to skip compiling some functions
like Init_vm_eval.
win32/mkexports.rb: export thread/ec functions, which are used by MJIT.
include/ruby/defines.h: add MJIT_FUNC_EXPORTED macro alis to clarify
that a function is exported only for MJIT.
array.c: export a function used by MJIT.
bignum.c: ditto.
class.c: ditto.
compile.c: ditto.
error.c: ditto.
gc.c: ditto.
hash.c: ditto.
iseq.c: ditto.
numeric.c: ditto.
object.c: ditto.
proc.c: ditto.
re.c: ditto.
st.c: ditto.
string.c: ditto.
thread.c: ditto.
variable.c: ditto.
vm_backtrace.c: ditto.
vm_insnhelper.c: ditto.
vm_method.c: ditto.
I would like to improve maintainability of function exports, but I
believe this way is acceptable as initial merging if we clarify the
new exports are for MJIT (so that we can use them as TODO list to fix)
and add unit tests to detect unresolved symbols.
I'll add unit tests of JIT compilations in succeeding commits.
Author: Takashi Kokubun <takashikkbn@gmail.com>
Contributor: wanabe <s.wanabe@gmail.com>
Part of [Feature #14235]
---
* Known issues
* Code generated by gcc is faster than clang. The benchmark may be worse
in macOS. Following benchmark result is provided by gcc w/ Linux.
* Performance is decreased when Google Chrome is running
* JIT can work on MinGW, but it doesn't improve performance at least
in short running benchmark.
* Currently it doesn't perform well with Rails. We'll try to fix this
before release.
---
* Benchmark reslts
Benchmarked with:
Intel 4.0GHz i7-4790K with 16GB memory under x86-64 Ubuntu 8 Cores
- 2.0.0-p0: Ruby 2.0.0-p0
- r62186: Ruby trunk (early 2.6.0), before MJIT changes
- JIT off: On this commit, but without `--jit` option
- JIT on: On this commit, and with `--jit` option
** Optcarrot fps
Benchmark: https://github.com/mame/optcarrot
| |2.0.0-p0 |r62186 |JIT off |JIT on |
|:--------|:--------|:--------|:--------|:--------|
|fps |37.32 |51.46 |51.31 |58.88 |
|vs 2.0.0 |1.00x |1.38x |1.37x |1.58x |
** MJIT benchmarks
Benchmark: https://github.com/benchmark-driver/mjit-benchmarks
(Original: https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch/MJIT-benchmarks)
| |2.0.0-p0 |r62186 |JIT off |JIT on |
|:----------|:--------|:--------|:--------|:--------|
|aread |1.00 |1.09 |1.07 |2.19 |
|aref |1.00 |1.13 |1.11 |2.22 |
|aset |1.00 |1.50 |1.45 |2.64 |
|awrite |1.00 |1.17 |1.13 |2.20 |
|call |1.00 |1.29 |1.26 |2.02 |
|const2 |1.00 |1.10 |1.10 |2.19 |
|const |1.00 |1.11 |1.10 |2.19 |
|fannk |1.00 |1.04 |1.02 |1.00 |
|fib |1.00 |1.32 |1.31 |1.84 |
|ivread |1.00 |1.13 |1.12 |2.43 |
|ivwrite |1.00 |1.23 |1.21 |2.40 |
|mandelbrot |1.00 |1.13 |1.16 |1.28 |
|meteor |1.00 |2.97 |2.92 |3.17 |
|nbody |1.00 |1.17 |1.15 |1.49 |
|nest-ntimes|1.00 |1.22 |1.20 |1.39 |
|nest-while |1.00 |1.10 |1.10 |1.37 |
|norm |1.00 |1.18 |1.16 |1.24 |
|nsvb |1.00 |1.16 |1.16 |1.17 |
|red-black |1.00 |1.02 |0.99 |1.12 |
|sieve |1.00 |1.30 |1.28 |1.62 |
|trees |1.00 |1.14 |1.13 |1.19 |
|while |1.00 |1.12 |1.11 |2.41 |
** Discourse's script/bench.rb
Benchmark: https://github.com/discourse/discourse/blob/v1.8.7/script/bench.rb
NOTE: Rails performance was somehow a little degraded with JIT for now.
We should fix this.
(At least I know opt_aref is performing badly in JIT and I have an idea
to fix it. Please wait for the fix.)
*** JIT off
Your Results: (note for timings- percentile is first, duration is second in millisecs)
categories_admin:
50: 17
75: 18
90: 22
99: 29
home_admin:
50: 21
75: 21
90: 27
99: 40
topic_admin:
50: 17
75: 18
90: 22
99: 32
categories:
50: 35
75: 41
90: 43
99: 77
home:
50: 39
75: 46
90: 49
99: 95
topic:
50: 46
75: 52
90: 56
99: 101
*** JIT on
Your Results: (note for timings- percentile is first, duration is second in millisecs)
categories_admin:
50: 19
75: 21
90: 25
99: 33
home_admin:
50: 24
75: 26
90: 30
99: 35
topic_admin:
50: 19
75: 20
90: 25
99: 30
categories:
50: 40
75: 44
90: 48
99: 76
home:
50: 42
75: 48
90: 51
99: 89
topic:
50: 49
75: 55
90: 58
99: 99
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62197 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* include/ruby/ruby.h (rb_varargs_argc_valid_p): relax rb_funcall
check on extra args only if argc == 0, for the compatibility
with wrong code which is probably confused with rb_funcallv.
[Bug #14425]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62151 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
clang 5.+ (tested clang 7.0.0) seems to be attempting division-by-zero
and giving a very large number for static args to rb_funcall.
* include/ruby/ruby.h (rb_varargs_bad_length): relax check for clang
* ext/-test-/funcall/funcall.c: renamed from passing_block.c
define extra_args_name function
* test/-ext-/funcall/test_funcall.rb: new test
[ruby-core:85266] [Bug #14425]
From: Eric Wong <e@80x24.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62116 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
And remove redundant `HAVE_*` macros,
and use `USE_RB_*` macros instead.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62067 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* include/ruby/missing.h (nan): need to declare the prototype of nan() if
missing.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62061 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Needlessly exporting can reduce performance locally and increase
binary size.
Increasing the footprint of our C-API larger is also detrimental
to our development as it encourages tighter coupling with our
internals; making it harder for us to preserve compatibility.
If some parts of the core codebase needs access to globals,
internal.h should be used instead of anything in include/ruby/*.
"Urabe, Shyouhei" <shyouhei@ruby-lang.org> wrote:
> On Thu, Jan 18, 2018 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > shyouhei@ruby-lang.org wrote:
> >> https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=61908
> >>
> >> export rb_mFConst
> >
> > Why are we exporting all these and making the public C-API bigger?
> > If anything, we should make these static. Thanks.
>
> No concrete reason, except they have already been externed in 2.5.
> These variables had lacked declarations so far, which resulted in their
> visibility to be that of extern. The commit is just confirming the status quo.
>
> I'm not against to turn them into static.
This reverts changes from r61910, r61909, r61908, r61907, and r61906.
* transcode.c (rb_eUndefinedConversionError): make static
(rb_eInvalidByteSequenceError): ditto
(rb_eConverterNotFoundError): ditto
* process.c (rb_mProcGID, rb_mProcUid, rb_mProcID_Syscall): ditto
* file.c (rb_mFConst): ditto
* error.c (rb_mWarning, rb_cWarningBuffer): ditto
* enumerator.c (rb_cLazy): ditto
[Misc #14381]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62029 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
POSIX only defines mode_t to be "an integer typea", and in fact
MacOS defines it to be uint16_t. We didn't have NUM2USHORT before
so it did not make sense but now that we have it. Why not check
apptopriately.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61950 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It seems HUGE_VAL is already used. Why not eliminate INTINITY.
NAN is also float. That of double is called nan(). This is also
fixed.
Signed-off-by: Urabe, Shyouhei <shyouhei@ruby-lang.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61938 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* include/ruby/defines.h (RUBY_ALIGNAS): Fix macro definition.
Fix compile error with Fujitsu C Compiler (fcc) on Solaris.
* include/ruby/defines.h (RUBY_ALIGNOF): Fix macro argument name.
Fix compile error with fcc and Oracle Solaris Studio 12.4 on Solaris.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61869 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
win32ole.c includes ALLOCA_N(struct myCPINFOEX, 1). On such case
it is not a wise idea to align to the size of that struct.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61843 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It seems to be a false positive that the configure detects this
undocumented function to be available on the compiler.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61836 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rb_setup_fake_str() can take arbitrary char* address, typicalluy
C string literals. These arguments have no guarantee of
alignment at all. It was not a wise idea for me to think
RSTRING_PTR can be aligned.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61835 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Before this NORETURN was checked only for __attribute__ or __declspec,
but nowadays other ways are there to tell compilers that a function
never returns. Take them into account.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61831 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
ALLOCA_N takes type arugment. It is natural that the returned
value to be used as an array of type, thus type-aligned.
Luckily GCC has a builtin to tell compiler such alignment info.
This should generate beter instructions.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61830 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
C11 and C++11 has this feature so why not use it when available.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61828 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For instance array.c:rb_ary_product() uses RSTRING_PTR() as an
array of int. So to avoid misaligned memory access RSTRING_PTR()
must at least be sizeof(int)-aligned. However the type of
RSTRING_PTR() is char*, which of course can expect alignment as
much as 1. This is a problem.
The reality is, there is no misaligned memory access because the
memory region behind RSTRING_PTR() is allocated using malloc().
Memory regions returned from malloc() are always aligned
appropriately. So let's tell the compiler about this information.
It seems GCC, clang, and MSVC have such feature.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61827 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
GCC 4.8 with optimization causes error if it compiles following code.
[Bug #14221]
```c
__builtin_choose_expr(__builtin_constant_p(b),0,1)
```
https://github.com/ruby/ruby/pull/1778
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61429 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
2.5's line coverage measurement was about two times slower than 2.4
because of two reasons; (1) vm_trace uses rb_iseq_event_flags (which
takes O(n) currently where n is the length of iseq) to get an event
type, and (2) RUBY_EVENT_LINE uses setjmp to call an event hook.
This change adds a special event for line coverage,
RUBY_EVENT_COVERAGE_LINE, and adds `tracecoverage` instructions where
the event occurs in iseq.
`tracecoverage` instruction calls an event hook without vm_trace.
And, RUBY_EVENT_COVERAGE_LINE is an internal event which does not
use setjmp.
This change also cancells lineno change due to the deletion of trace
instructions [Feature #14104]. So fixes [Bug #14191].
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61350 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
FrozenError will be used instead of RuntimeError for exceptions
raised when there is an attempt to modify a frozen object. The
reason for this change is to differentiate exceptions related
to frozen objects from generic exceptions such as those generated
by Kernel#raise without an exception class.
From: Jeremy Evans <code@jeremyevans.net>
Signed-off-by: Urabe Shyouhei <shyouhei@ruby-lang.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61131 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This change moves RUBY_EVENT_COVERAGE from include/ruby/ruby.h to
vm_core.h and renames it to RUBY_EVENT_COVERAGE_BRANCH.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61049 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Support nanosec file timestamp on Windows 8 or later.
Original patches are written by kubo (Kubo Takehiro).
Windows 7 and earlier also supports nanosec file timestamp, but it's too
accurate than system time. so, this feature is disabled on such versions.
[Feature #13726]
this change also includes [Misc #13702]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61013 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
because it was actually used in
https://github.com/tmm1/rbtrace/blob/v0.4.8/ext/rbtrace.c#L329
and deprecated in r60579 AFTER removal in r60558.
ko1 agreed that we should keep just deprecated in Ruby 2.5 and remove it
later, and I'm commiting this because I want to make rbtrace.gem
installation successful.
backward.h: modify r60579 to make rb_frame_method_id_and_class()
compilable.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60964 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
