summaryrefslogtreecommitdiff
path: root/vm.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove unneeded repetitionsTakashi Kokubun2023-02-041-1/+1
|
* use correct svar (#7225)Koichi Sasada2023-02-011-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * use correct svar Without this patch, svar location is used "nearest Ruby frame". It is almost correct but it doesn't correct when the `each` method is written in Ruby. ```ruby class C include Enumerable def each %w(bar baz).each{|e| yield e} end end C.new.grep(/(b.)/){|e| p [$1, e]} ``` This patch fix this issue by traversing ifunc's cfp. Note that if cfp doesn't specify this Thread's cfp stack, reserved svar location (`ec->root_svar`) is used. * make yjit-bindgen --------- Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
* Fix off-by-one error in rb_vm_each_stack_valuePeter Zhu2023-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applying the following patch to test/erb/test_erb.rb and running that file will cause Ruby to crash on my machine (macOS 13.1 on M1 Pro): ``` --- a/test/erb/test_erb.rb +++ b/test/erb/test_erb.rb @@ -7,6 +7,12 @@ class TestERB < Test::Unit::TestCase class MyError < RuntimeError ; end + def setup + GC.auto_compact = true + GC.stress = true + GC.verify_compaction_references(expand_heap: true, toward: :empty) + end + ``` It crashes with the following log: ``` /Users/peter/src/ruby/lib/erb/compiler.rb:276: [BUG] Segmentation fault at 0x00000001083a8690 ... -- C level backtrace information ------------------------------------------- ... /Users/peter/src/ruby/build/ruby(rb_vm_each_stack_value+0xa8) [0x104cc3a44] ../vm.c:2737 /Users/peter/src/ruby/build/ruby(rb_vm_each_stack_value+0xa8) [0x104cc3a44] ../vm.c:2737 /Users/peter/src/ruby/build/ruby(check_stack_for_moved+0x2c) [0x104b272a4] ../gc.c:5512 /Users/peter/src/ruby/build/ruby(gc_compact_finish) ../gc.c:5534 /Users/peter/src/ruby/build/ruby(gc_sweep_compact) ../gc.c:8653 /Users/peter/src/ruby/build/ruby(gc_sweep) ../gc.c:6196 /Users/peter/src/ruby/build/ruby(has_sweeping_pages+0x0) [0x104b19c54] ../gc.c:9568 /Users/peter/src/ruby/build/ruby(gc_rest) ../gc.c:9570 ``` This crash happens because it's reading the VALUE at sp. But since sp points to the top of the stack, it's reading the VALUE above the top of the stack, which is causing this segfault. Fixes [Bug #19320]
* MJIT: Cancel all on disastrous situations (#7019)Takashi Kokubun2022-12-241-0/+1
| | | | | | | | | | I noticed this while running test_yjit with --mjit-call-threshold=1, which redefines `Integer#<`. When Ruby is monkey-patched, MJIT itself could be broken. Similarly, Ruby scripts could break MJIT in many different ways. I prepared the same set of hooks as YJIT so that we could possibly override it and disable it on those moments. Every constant under RubyVM::MJIT is private and thus it's an unsupported behavior though.
* Use a BOP for Hash#defaultJohn Hawthorn2022-12-171-0/+1
| | | | | | | | | | | | | | | | | | | | On a hash miss we need to call default if it is redefined in order to return the default value to be used. Previously we checked this with rb_method_basic_definition_p, which avoids the method call but requires a method lookup. This commit replaces the previous check with BASIC_OP_UNREDEFINED_P and a new BOP_DEFAULT. We still need to fall back to rb_method_basic_definition_p when called on a subclasss of hash. | |compare-ruby|built-ruby| |:---------------|-----------:|---------:| |hash_aref_miss | 2.692| 3.531| | | -| 1.31x| Co-authored-by: Daniel Colson <danieljamescolson@gmail.com> Co-authored-by: "Ian C. Anderson" <ian@iancanderson.com> Co-authored-by: Jack McCracken <me@jackmc.xyz>
* MJIT: Give a more appropriate name to the initial stateTakashi Kokubun2022-12-081-4/+4
|
* Add debug counters to RubyVM.stat (#6086)Chris Seaton2022-12-071-0/+19
| | | | | | | | | * Add debug counters to RubyVM.stat * Use SIZET2NUM Co-author: Nobuyoshi Nakada <nobu@ruby-lang.org> * Prefix debug_counter_names
* MJIT: Refactor the jit_func enum for MJITTakashi Kokubun2022-12-061-8/+7
| | | | | | All values should have a MJIT_ prefix. We could address the warning for the end mark if we just define the macro for the check next to the enum. It even simplifies some code for checking the enum.
* Introduce BOP_CMP for optimized comparisonDaniel Colson2022-12-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this commit the `OPTIMIZED_CMP` macro relied on a method lookup to determine whether `<=>` was overridden. The result of the lookup was cached, but only for the duration of the specific method that initialized the cmp_opt_data cache structure. With this method lookup, `[x,y].max` is slower than doing `x > y ? x : y` even though there's an optimized instruction for "new array max". (John noticed somebody a proposed micro-optimization based on this fact in https://github.com/mastodon/mastodon/pull/19903.) ```rb a, b = 1, 2 Benchmark.ips do |bm| bm.report('conditional') { a > b ? a : b } bm.report('method') { [a, b].max } bm.compare! end ``` Before: ``` Comparison: conditional: 22603733.2 i/s method: 19820412.7 i/s - 1.14x (± 0.00) slower ``` This commit replaces the method lookup with a new CMP basic op, which gives the examples above equivalent performance. After: ``` Comparison: method: 24022466.5 i/s conditional: 23851094.2 i/s - same-ish: difference falls within error ``` Relevant benchmarks show an improvement to Array#max and Array#min when not using the optimized newarray_max instruction as well. They are noticeably faster for small arrays with the relevant types, and the same or maybe a touch faster on larger arrays. ``` $ make benchmark COMPARE_RUBY=<master@5958c305> ITEM=array_min $ make benchmark COMPARE_RUBY=<master@5958c305> ITEM=array_max ``` The benchmarks added in this commit also look generally improved. Co-authored-by: John Hawthorn <jhawthorn@github.com>
* Move BOP macros to separate fileDaniel Colson2022-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit moves ruby_basic_operators and the unredefined macros out of vm_core.h and into basic_operators.h so that we can use them more broadly in places where we currently use a method look up via `rb_method_basic_definition_p` (e.g. object.c, numeric.c, complex.c, enum.c, but also in internal/compar.h after introducing BOP_CMP and elsewhere if we introduce more BOPs) The most controversial part of this change is probably moving redefined_flag out of rb_vm_t. [vm_opt_method_def_table and vm_opt_mid_table](https://github.com/ruby/ruby/blob/9da2a5204f32a4f2ce135fddde2abb6e07d647e9/vm.c) are not part of rb_vm_t either, and I think this fits well with those. But more significantly it seems to result in one fewer instruction. For example: Before: ``` (lldb) disassemble -n vm_opt_str_freeze miniruby`vm_exec_core: miniruby[0x10028233e] <+14558>: movq 0x11a86b(%rip), %rax ; ruby_current_vm_ptr miniruby[0x100282345] <+14565>: testb $0x4, 0x242c(%rax) ``` After: ``` (lldb) disassemble -n vm_opt_str_freeze ruby`vm_exec_core: ruby[0x100280ebe] <+14510>: testb $0x4, 0x120147(%rip) ; ruby_vm_redefined_flag + 43 ``` Co-authored-by: John Hawthorn <jhawthorn@github.com>
* Introduce `Fiber#storage` for inheritable fiber-scoped variables. (#6612)Samuel Williams2022-12-011-1/+7
|
* Fix autoload status of statically linked extensionsAlan Wu2022-11-251-0/+3
| | | | | | | | | | | | | | | | | | Previously, for statically-linked extensions, we used `vm->loading_table` to delay calling the init function until the extensions are required. This caused the extensions to look like they are in the middle of being loaded even before they're required. (`rb_feature_p()` returned true with a loading path output.) Combined with autoload, queries like `defined?(CONST)` and `Module#autoload?` were confused by this and returned nil incorrectly. RubyGems uses `defined?` to detect if OpenSSL is available and failed when OpenSSL was available in builds using `--with-static-linked-ext`. Use a dedicated table for the init functions instead of adding them to the loading table. This lets us remove some logic from non-EXTSTATIC builds. [Bug #19115]
* Add next_shape_id to vm statsAaron Patterson2022-11-231-1/+3
| | | | | | We need to track this number in CI. It's important to know how changes to the codebase impact the number of shapes in the system, so lets add the number to the VM stat hash
* Using UNDEF_P macroS-H-GAMELINKS2022-11-161-6/+6
|
* Rename --mjit-min-calls to --mjit-call-threshold (#6731)Takashi Kokubun2022-11-141-1/+1
| | | for consistency with YJIT
* Reduce the number of branches in jit_exec (#6722)Takashi Kokubun2022-11-131-30/+23
| | | | | | | * Reduce the number of branches in jit_exec * Address build failure in some configurations * Refactor yjit.h
* s/mjit_func_t/jit_func_t/Takashi Kokubun2022-11-131-1/+1
|
* Remove unused debug countersTakashi Kokubun2022-11-131-21/+1
| | | | | | The structure and readability of jit_exec is messed up right now. I'd like to help the current situation by this for now. I'll resurrect them when I need it again.
* Transition shape when object's capacity changesJemma Issroff2022-11-101-11/+0
| | | | | | | | | | | | | | | | This commit adds a `capacity` field to shapes, and adds shape transitions whenever an object's capacity changes. Objects which are allocated out of a bigger size pool will also make a transition from the root shape to the shape with the correct capacity for their size pool when they are allocated. This commit will allow us to remove numiv from objects completely, and will also mean we can guarantee that if two objects share shapes, their IVs are in the same positions (an embedded and extended object cannot share shapes). This will enable us to implement ivar sets in YJIT using object shapes. Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>
* Fix -Wundef warningsNobuyoshi Nakada2022-10-261-1/+1
|
* Remove unused class serialJemma Issroff2022-10-211-12/+1
| | | | | | | | Before object shapes, we were using class serial to invalidate inline caches. Now that we use shape_id for inline cache keys, the class serial is unnecessary. Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>
* push dummy frame for loading processKoichi Sasada2022-10-201-11/+14
| | | | | | | | | | | | | This patch pushes dummy frames when loading code for the profiling purpose. The following methods push a dummy frame: * `Kernel#require` * `Kernel#load` * `RubyVM::InstructionSequence.compile_file` * `RubyVM::InstructionSequence.load_from_binary` https://bugs.ruby-lang.org/issues/18559
* Make inline cache reads / writes atomic with object shapesJemma Issroff2022-10-111-2/+2
| | | | | | | | | | | | | | Prior to this commit, we were reading and writing ivar index and shape ID in inline caches in two separate instructions when getting and setting ivars. This meant there was a race condition with ractors and these caches where one ractor could change a value in the cache while another was still reading from it. This commit instead reads and writes shape ID and ivar index to inline caches atomically so there is no longer a race condition. Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org> Co-Authored-By: John Hawthorn <john@hawthorn.email>
* Revert "Revert "This commit implements the Object Shapes technique in CRuby.""Jemma Issroff2022-10-111-0/+31
| | | | This reverts commit 9a6803c90b817f70389cae10d60b50ad752da48f.
* Revert "This commit implements the Object Shapes technique in CRuby."Aaron Patterson2022-09-301-31/+0
| | | | This reverts commit 68bc9e2e97d12f80df0d113e284864e225f771c2.
* This commit implements the Object Shapes technique in CRuby.Jemma Issroff2022-09-281-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Object Shapes is used for accessing instance variables and representing the "frozenness" of objects. Object instances have a "shape" and the shape represents some attributes of the object (currently which instance variables are set and the "frozenness"). Shapes form a tree data structure, and when a new instance variable is set on an object, that object "transitions" to a new shape in the shape tree. Each shape has an ID that is used for caching. The shape structure is independent of class, so objects of different types can have the same shape. For example: ```ruby class Foo def initialize # Starts with shape id 0 @a = 1 # transitions to shape id 1 @b = 1 # transitions to shape id 2 end end class Bar def initialize # Starts with shape id 0 @a = 1 # transitions to shape id 1 @b = 1 # transitions to shape id 2 end end foo = Foo.new # `foo` has shape id 2 bar = Bar.new # `bar` has shape id 2 ``` Both `foo` and `bar` instances have the same shape because they both set instance variables of the same name in the same order. This technique can help to improve inline cache hits as well as generate more efficient machine code in JIT compilers. This commit also adds some methods for debugging shapes on objects. See `RubyVM::Shape` for more details. For more context on Object Shapes, see [Feature: #18776] Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org> Co-Authored-By: Eileen M. Uchitelle <eileencodes@gmail.com> Co-Authored-By: John Hawthorn <john@hawthorn.email>
* Revert this until we can figure out WB issues or remove shapes from GCAaron Patterson2022-09-261-45/+0
| | | | | | | | | | Revert "* expand tabs. [ci skip]" This reverts commit 830b5b5c351c5c6efa5ad461ae4ec5085e5f0275. Revert "This commit implements the Object Shapes technique in CRuby." This reverts commit 9ddfd2ca004d1952be79cf1b84c52c79a55978f4.
* This commit implements the Object Shapes technique in CRuby.Jemma Issroff2022-09-261-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Object Shapes is used for accessing instance variables and representing the "frozenness" of objects. Object instances have a "shape" and the shape represents some attributes of the object (currently which instance variables are set and the "frozenness"). Shapes form a tree data structure, and when a new instance variable is set on an object, that object "transitions" to a new shape in the shape tree. Each shape has an ID that is used for caching. The shape structure is independent of class, so objects of different types can have the same shape. For example: ```ruby class Foo def initialize # Starts with shape id 0 @a = 1 # transitions to shape id 1 @b = 1 # transitions to shape id 2 end end class Bar def initialize # Starts with shape id 0 @a = 1 # transitions to shape id 1 @b = 1 # transitions to shape id 2 end end foo = Foo.new # `foo` has shape id 2 bar = Bar.new # `bar` has shape id 2 ``` Both `foo` and `bar` instances have the same shape because they both set instance variables of the same name in the same order. This technique can help to improve inline cache hits as well as generate more efficient machine code in JIT compilers. This commit also adds some methods for debugging shapes on objects. See `RubyVM::Shape` for more details. For more context on Object Shapes, see [Feature: #18776] Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org> Co-Authored-By: Eileen M. Uchitelle <eileencodes@gmail.com> Co-Authored-By: John Hawthorn <john@hawthorn.email>
* Do not fork the process on --mjit-waitTakashi Kokubun2022-09-061-2/+2
| | | | | fork is for parallel compilation, but --mjit-wait cancels it. It's more useful to not fork it for binding.irb, debugging, etc.
* Introduce `usage_analysis_clear`S.H2022-08-291-26/+23
|
* Rename mjit_exec to jit_exec (#6262)Takashi Kokubun2022-08-191-14/+14
| | | | | | | * Rename mjit_exec to jit_exec * Rename mjit_exec_slowpath to mjit_check_iseq * Remove mjit_exec references from comments
* Move `mjit_exec` to vm.cNobuyoshi Nakada2022-08-171-0/+97
|
* Simplify around `USE_YJIT` macro (#6240)Nobuyoshi Nakada2022-08-151-1/+1
| | | | | | | | * Simplify around `USE_YJIT` macro - Use `USE_YJIT` macro only instead of `YJIT_BUILD`. - An intermediate macro `YJIT_SUPPORTED_P` is no longer used. * Bail out if YJIT is enabled on unsupported platforms
* Rename rb_ary_tmp_new to rb_ary_hidden_newPeter Zhu2022-07-261-1/+1
| | | | | | 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.
* Add "rb_" prefixes to toplevel enum definitionsYusuke Endoh2022-07-221-1/+1
| | | | ... as per ko1's request.
* Expand tabs [ci skip]Takashi Kokubun2022-07-211-567/+567
| | | | [Misc #18891]
* Prevent the stack from being marked twiceAaron Patterson2022-07-201-2/+1
| | | | | | | This commit prevents the stack from being marked twice: once via the Fiber, and once via the Thread. It introduces an assertion to assert that the ec on the thread is the same as the ec on the Fiber being marked via the thread.
* Fix infinite loop when b_return TracePoint throwsAlan Wu2022-06-221-2/+2
| | | | | | | | | Previously, we didn't pop the frame that runs the TracePoint hook for b_return events for blocks running as methods (bmethods). In case the hook raises, that formed an infinite loop during stack unwinding in hook_before_rewind(). [Bug #18060]
* Move RubyVM::MJIT to builtin RubyTakashi Kokubun2022-06-151-39/+0
| | | | just less C code to maintain
* remove `NON_SCALAR_THREAD_ID` supportKoichi Sasada2022-05-241-4/+0
| | | | | | | | | `NON_SCALAR_THREAD_ID` shows `pthread_t` is non-scalar (non-pointer) and only s390x is known platform. However, the supporting code is very complex and it is only used for deubg print information. So this patch removes the support of `NON_SCALAR_THREAD_ID` and make the code simple.
* setup vm->main_ractor before `Init_native_thread()`Koichi Sasada2022-05-201-5/+6
|
* `rb_thread_t::serial` for debugKoichi Sasada2022-05-201-0/+5
| | | | | | | | | | | `rb_thread_t::serial` is auto-incremented serial number for threads and it can overflow, it means the serial is not a ID for each thread, it is only for debug print. `RUBY_DEBUG_LOG` shows this information. Also skip EC related information if EC is NULL. This patch enable to use `RUBY_DEBUG_LOG` without setup EC.
* Delete autoload data from global features after autoload has completed. (#5910)Samuel Williams2022-05-171-2/+2
| | | | | * Update naming of critical section assertions macros. * Improved locking for autoload.
* Fix various autoload race conditions. (#5898)Samuel Williams2022-05-151-0/+4
| | | | | | | | | | | * Add RUBY_VM_CRITICAL_SECTION for detecting unexpected context switch. * Prevent race between GC mark and autoload setup. * Protect race on autoload state. * Avoid potential race condition when allocating `autoload_featuremap`. * Add NEWS entry for autoload fixes.
* Rust YJITAlan Wu2022-04-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* introduce struct `rb_native_thread`Koichi Sasada2022-04-231-7/+6
| | | | | | | | | `rb_thread_t` contained `native_thread_data_t` to represent thread implementation dependent data. This patch separates them and rename it `rb_native_thread` and point it from `rb_thraed_t`. Now, 1 Ruby thread (`rb_thread_t`) has 1 native thread (`rb_native_thread`).
* refactoring thread inits in vm.cKoichi Sasada2022-04-231-30/+22
| | | | | | * `th_init` accepts vm and ractor. * remove `ruby_thread_init` because it is duplicated with `th_init`. * add some comments.
* Uncomment code to raise LocalJumpError for yield across thread through enumJeremy Evans2022-04-211-2/+0
| | | | | | | | Not sure if this is the correct fix. It does raise LocalJumpError in the yielding thread as you would expect, but the value yielded to the calling thread is still yielded without an exception. Fixes [Bug #18649]
* Raise RuntimeError if Kernel#binding is called from a non-Ruby frameJeremy Evans2022-04-061-7/+4
| | | | | | | | | Check whether the current or previous frame is a Ruby frame in call_trace_func and rb_tracearg_binding before attempting to create a binding for the frame. Fixes [Bug #18487] Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
* RubyVM.stat constant cache metrics (#5766)Kevin Newton2022-04-051-32/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Before the new constant cache behavior, caches were invalidated by a single global variable. You could inspect the value of this variable with RubyVM.stat(:global_constant_state). This was mostly useful to verify the behavior of the VM or to test constant loading like in Rails. With the new constant cache behavior, we introduced RubyVM.stat(:constant_cache) which returned a hash with symbol keys and integer values that represented the number of live constant caches associated with the given symbol. Additionally, we removed the old RubyVM.stat(:global_constant_state). This was proven to be not very useful, so it doesn't help you diagnose constant loading issues. So, instead we added the global constant state back into the RubyVM output. However, that number can be misleading as now when you invalidate something like `Foo::Bar::Baz` you're actually invalidating 3 different lists of inline caches. This commit attempts to get the best of both worlds. We remove RubyVM.stat(:global_constant_state) like we did originally, as it doesn't have the same semantic meaning and it could be confusing going forward. Instead we add RubyVM.stat(:constant_cache_invalidations) and RubyVM.stat(:constant_cache_misses). These two metrics should provide enough information to diagnose any constant loading issues, as well as provide a replacement for the old global constant state.
View Lorry Controller Status