| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
When LOAD_RELATIVE, as `sopath` is truncated to the prefix path, make
the duplicate before it. Also make `rb_libruby_selfpath` frozen and
hidden.
|
| |
|
| |
|
|
|
|
|
|
| |
rb_ary_tmp_new suggests that the array is temporary in some way, but
that's not true, it just creates an array that's hidden and not on the
transient heap. This commit renames it to rb_ary_hidden_new.
|
|
|
|
| |
[Misc #18891]
|
| |
|
| |
|
|
|
|
|
| |
Usually, command line options are given precedence first, environment
variables next, and fall back to configuration options at last.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
YJIT is now a build-time opt-in so on platforms that YJIT could support
it could still be unavailable due to user discretion. Use MJIT for --jit
and don't display YJIT related command line options in --help when YJIT
is not included in the build.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since enabling YJIT or MJIT drastically changes what could go wrong at
runtime, it's good to be front and center about whether they are enabled
when dumping a crash report. Previously, `RUBY_DESCRIPTION` and the
description printed when crashing can be different when a JIT is on.
Introduce a new internal data global, `rb_dynamic_description`, and set
it to be the same as `RUBY_DESCRIPTION` during initialization; use it
when crashing.
* version.c: Init_ruby_description(): Initialize and use
`rb_dynamic_description`.
* error.c: Change crash reports to use `rb_dynamic_description`.
* ruby.c: Call `Init_ruby_description()` earlier. Slightly more work
for when we exit right after printing the description but that
was deemed acceptable.
* include/ruby/version.h: Talk about how JIT info is not in
`ruby_description`.
* test/-ext-/bug_reporter/test_bug_reporter.rb: Remove handling for
crash description being different from `RUBY_DESCRIPTION`.
* test/ruby/test_rubyoptions.rb: ditto
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In December 2021, we opened an [issue] to solicit feedback regarding the
porting of the YJIT codebase from C99 to Rust. There were some
reservations, but this project was given the go ahead by Ruby core
developers and Matz. Since then, we have successfully completed the port
of YJIT to Rust.
The new Rust version of YJIT has reached parity with the C version, in
that it passes all the CRuby tests, is able to run all of the YJIT
benchmarks, and performs similarly to the C version (because it works
the same way and largely generates the same machine code). We've even
incorporated some design improvements, such as a more fine-grained
constant invalidation mechanism which we expect will make a big
difference in Ruby on Rails applications.
Because we want to be careful, YJIT is guarded behind a configure
option:
```shell
./configure --enable-yjit # Build YJIT in release mode
./configure --enable-yjit=dev # Build YJIT in dev/debug mode
```
By default, YJIT does not get compiled and cargo/rustc is not required.
If YJIT is built in dev mode, then `cargo` is used to fetch development
dependencies, but when building in release, `cargo` is not required,
only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer.
The YJIT command-line options remain mostly unchanged, and more details
about the build process are documented in `doc/yjit/yjit.md`.
The CI tests have been updated and do not take any more resources than
before.
The development history of the Rust port is available at the following
commit for interested parties:
https://github.com/Shopify/ruby/commit/1fd9573d8b4b65219f1c2407f30a0a60e537f8be
Our hope is that Rust YJIT will be compiled and included as a part of
system packages and compiled binaries of the Ruby 3.2 release. We do not
anticipate any major problems as Rust is well supported on every
platform which YJIT supports, but to make sure that this process works
smoothly, we would like to reach out to those who take care of building
systems packages before the 3.2 release is shipped and resolve any
issues that may come up.
[issue]: https://bugs.ruby-lang.org/issues/18481
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
Co-authored-by: Noah Gibbs <the.codefolio.guy@gmail.com>
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
|
|
|
|
|
|
|
| |
Add a hook point to initialize extra extension libraries. The default
hook function is replaced when linking a strong `Init_extra_exts`
symbol. A builder can insert an object file that defines Init_extra_exts
by XLDFLAGS.
|
|
|
|
|
| |
IA64 support was dropped in ticket #15894, so we can drop support for
HP-UX.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
compiling ../ruby.c
../ruby.c:1547:17: error: implicit declaration of function 'setup_yjit_options' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
setup_yjit_options(s, &opt->yjit);
^
../ruby.c:1547:17: note: did you mean 'setup_mjit_options'?
../ruby.c:1122:1: note: 'setup_mjit_options' declared here
setup_mjit_options(const char *s, struct mjit_options *mjit_opt)
^
../ruby.c:1547:45: error: no member named 'yjit' in 'struct ruby_cmdline_options'; did you mean 'mjit'?
setup_yjit_options(s, &opt->yjit);
^~~~
mjit
../ruby.c:192:25: note: 'mjit' declared here
struct mjit_options mjit;
^
../ruby.c:1924:28: error: no member named 'yjit' in 'struct ruby_cmdline_options'; did you mean 'mjit'?
rb_yjit_init(&opt->yjit);
^~~~
mjit
../ruby.c:192:25: note: 'mjit' declared here
struct mjit_options mjit;
^
3 errors generated.
```
|
| |
|
| |
|
| |
|
|
|
|
| |
changed at 028f1887c2bfa50dcfc1b623470d6ab1b880fdde
|
|
|
|
| |
`--yjit-call-threshold` and `--yjit-max-versions` need an argument.
|
|
|
|
|
|
| |
We need to unshare the array loaded_features because the shared root
could be old gen (while loaded_features is young) which causes a WB
miss.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Rename --jit to --mjit
[Feature #18349]
* Fix a few more --jit references
* Fix MJIT Actions
* More s/jit/mjit/ and re-introduce --disable-jit
* Update NEWS.md
* Fix test_bug_reporter_add
|
| |
|
| |
|
|
|
|
| |
This reverts commit 119626da947bf6492ef7a27abf3bf12de5d0d95a.
|
|
|
|
|
|
|
| |
* Add --yjit-no-type-prop so we can test YJIT without type propagation
* Fix typo in command line option
* Leave just two test workflows enable for YJIT
|
|
|
|
|
| |
This commit adds support for embedded strings with variable capacity and
uses Variable Width Allocation to allocate strings.
|
|
|
|
| |
--enable=all didn't work when cppflags=-DMJIT_FORCE_ENABLE was given.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TestRubyOptions#test_enable was broken on OpenBSD after the yjit
merge. --yjit (and --enable-all, which enables --yjit) fails on
OpenBSD because yjit uses an insecure mmap call (both writable
and executable), in alloc_exec_mem, which OpenBSD does not allow.
This can probably be reverted if yjit switches to a more secure
mmap design (writable xor executable). This would involve
initially calling mmap with PROT_READ | PROT_WRITE, and after writing
of executable code has finished, using mprotect to switch to
PROT_READ | PROT_EXEC. I believe Firefox uses this approach for
their Javascript engine since Firefox 46.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Previously, options such as "--yjit123" would enable YJIT. Additionally,
the error message for argument parsing mentioned "--jit-..." instead of
"--yjit-...".
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Add RUBY_YJIT_ENABLE env var and YJIT_FORCE_ENABLE compile-time constant.
Rename YJIT_STATS to RUBY_YJIT_STATS.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Compile time flag seems pretty forceful, so let MJIT turn on by default
if it is used.
|
| |
|
| |
|