summaryrefslogtreecommitdiff
path: root/vm.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove printf family from the mjit headerNobuyoshi Nakada2021-09-111-10/+10
| | | | | Linking printf family functions makes mjit objects to link unnecessary code.
* include/ruby/internal/intern/vm.h: add doxygen卜部昌平2021-09-101-2/+0
| | | | Must not be a bad idea to improve documents. [ci skip]
* Show verbose error messages when single pattern match failsKazuki Tsujimoto2021-08-151-0/+7
| | | | | | | [0] => [0, *, a] #=> [0] length mismatch (given 1, expected 2+) (NoMatchingPatternError) Ignore test failures of typeprof caused by this change for now.
* Fix potential hang when joining threads.Samuel Williams2021-08-031-7/+10
| | | | | | | | | | | If the thread termination invokes user code after `th->status` becomes `THREAD_KILLED`, and the user unblock function causes that `th->status` to become something else (e.g. `THREAD_RUNNING`), threads waiting in `thread_join_sleep` will hang forever. We move the unblock function call to before the thread status is updated, and allow threads to join as soon as `th->value` becomes defined. This reverts commit 6505c77501f1924571b2fe620c5c7b31ede0cd22.
* Using RBOOL macroS.H2021-08-021-13/+5
|
* use me->def instead of me for opt_tableKoichi Sasada2021-07-291-6/+5
| | | | | | | | | | | | `vm_opt_method_table` is me=>bop table to manage the optimized methods (by specialized instruction). However, `me` can be invalidated to invalidate the method cache entry. [Bug #17725] To solve the issue, use `me-def` instead of `me` which simply copied at invalidation timing. A test by @jeremyevans https://github.com/ruby/ruby/pull/4376
* Revert "Fix potential hang when joining threads."Yusuke Endoh2021-07-281-10/+7
| | | | | | | | | | | This reverts commit 13f8521c630a15c87398dee0763e95f59c032a94. http://rubyci.s3.amazonaws.com/solaris11-gcc/ruby-master/log/20210727T230009Z.fail.html.gz http://rubyci.s3.amazonaws.com/solaris11-sunc/ruby-master/log/20210728T000009Z.fail.html.gz This revert is to confirm whether the commit is the cause. If the failures consistently occur after this revert, I'll reintroduce the commit.
* Fix infinite loop in ensure after NoMemoryErrorJeremy Evans2021-07-271-1/+1
| | | | | | | | | | | | | | VM patch from wanabe. Test based on example from buzztaiki (Taiki Sugawara). Test fails when compiles with -DRUBY_DEBUG, as that can can use rb_bug instead of NoMemoryError, which doesn't allow testing this case. Test also fails on MingW, as RangeError is used instead of NoMemoryError. Skip the test in either case. Fixes [Bug #15779]
* Fix potential hang when joining threads.Samuel Williams2021-07-271-7/+10
| | | | | | | | | If the thread termination invokes user code after `th->status` becomes `THREAD_KILLED`, and the user unblock function causes that `th->status` to become something else (e.g. `THREAD_RUNNING`), threads waiting in `thread_join_sleep` will hang forever. We move the unblock function call to before the thread status is updated, and allow threads to join as soon as `th->value` becomes defined.
* Add debug assertion in `rb_funcall*` that the current thread has the gvl.Samuel Williams2021-07-161-0/+1
|
* Keep GC disabled until VM bootstrap has done [Bug #17583]Nobuyoshi Nakada2021-07-011-2/+2
|
* Add a cache for class variableseileencodes2021-06-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redo of 34a2acdac788602c14bf05fb616215187badd504 and 931138b00696419945dc03e10f033b1f53cd50f3 which were reverted. GitHub PR #4340. This change implements a cache for class variables. Previously there was no cache for cvars. Cvar access is slow due to needing to travel all the way up th ancestor tree before returning the cvar value. The deeper the ancestor tree the slower cvar access will be. The benefits of the cache are more visible with a higher number of included modules due to the way Ruby looks up class variables. The benchmark here includes 26 modules and shows with the cache, this branch is 6.5x faster when accessing class variables. ``` compare-ruby: ruby 3.1.0dev (2021-03-15T06:22:34Z master 9e5105c) [x86_64-darwin19] built-ruby: ruby 3.1.0dev (2021-03-15T12:12:44Z add-cache-for-clas.. c6be009) [x86_64-darwin19] | |compare-ruby|built-ruby| |:--------|-----------:|---------:| |vm_cvar | 5.681M| 36.980M| | | -| 6.51x| ``` Benchmark.ips calling `ActiveRecord::Base.logger` from within a Rails application. ActiveRecord::Base.logger has 71 ancestors. The more ancestors a tree has, the more clear the speed increase. IE if Base had only one ancestor we'd see no improvement. This benchmark is run on a vanilla Rails application. Benchmark code: ```ruby require "benchmark/ips" require_relative "config/environment" Benchmark.ips do |x| x.report "logger" do ActiveRecord::Base.logger end end ``` Ruby 3.0 master / Rails 6.1: ``` Warming up -------------------------------------- logger 155.251k i/100ms Calculating ------------------------------------- ``` Ruby 3.0 with cvar cache / Rails 6.1: ``` Warming up -------------------------------------- logger 1.546M i/100ms Calculating ------------------------------------- logger 14.857M (± 4.8%) i/s - 74.198M in 5.006202s ``` Lastly we ran a benchmark to demonstate the difference between master and our cache when the number of modules increases. This benchmark measures 1 ancestor, 30 ancestors, and 100 ancestors. Ruby 3.0 master: ``` Warming up -------------------------------------- 1 module 1.231M i/100ms 30 modules 432.020k i/100ms 100 modules 145.399k i/100ms Calculating ------------------------------------- 1 module 12.210M (± 2.1%) i/s - 61.553M in 5.043400s 30 modules 4.354M (± 2.7%) i/s - 22.033M in 5.063839s 100 modules 1.434M (± 2.9%) i/s - 7.270M in 5.072531s Comparison: 1 module: 12209958.3 i/s 30 modules: 4354217.8 i/s - 2.80x (± 0.00) slower 100 modules: 1434447.3 i/s - 8.51x (± 0.00) slower ``` Ruby 3.0 with cvar cache: ``` Warming up -------------------------------------- 1 module 1.641M i/100ms 30 modules 1.655M i/100ms 100 modules 1.620M i/100ms Calculating ------------------------------------- 1 module 16.279M (± 3.8%) i/s - 82.038M in 5.046923s 30 modules 15.891M (± 3.9%) i/s - 79.459M in 5.007958s 100 modules 16.087M (± 3.6%) i/s - 81.005M in 5.041931s Comparison: 1 module: 16279458.0 i/s 100 modules: 16087484.6 i/s - same-ish: difference falls within error 30 modules: 15891406.2 i/s - same-ish: difference falls within error ``` Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
* node.h: Reduce struct size to fit with Ruby object size (five VALUEs)Yusuke Endoh2021-06-181-1/+1
| | | | | | | | by merging `rb_ast_body_t#line_count` and `#script_lines`. Fortunately `line_count == RARRAY_LEN(script_lines)` was always satisfied. When script_lines is saved, it has an array of lines, and when not saved, it has a Fixnum that represents the old line_count.
* Adjust styles [ci skip]Nobuyoshi Nakada2021-06-171-1/+2
| | | | | | | | | * --braces-after-func-def-line * --dont-cuddle-else * --procnames-start-lines * --space-after-for * --space-after-if * --space-after-while
* Revert "Filling cache values on cvar write"Aaron Patterson2021-05-111-4/+1
| | | | | This reverts commit 08de37f9fa3469365e6b5c964689ae2bae0eb9f3. This reverts commit e8ae922b62adb00a80d3d4c49f7d7b0e6026eaba.
* Add a cache for class variableseileencodes2021-05-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change implements a cache for class variables. Previously there was no cache for cvars. Cvar access is slow due to needing to travel all the way up th ancestor tree before returning the cvar value. The deeper the ancestor tree the slower cvar access will be. The benefits of the cache are more visible with a higher number of included modules due to the way Ruby looks up class variables. The benchmark here includes 26 modules and shows with the cache, this branch is 6.5x faster when accessing class variables. ``` compare-ruby: ruby 3.1.0dev (2021-03-15T06:22:34Z master 9e5105ca45) [x86_64-darwin19] built-ruby: ruby 3.1.0dev (2021-03-15T12:12:44Z add-cache-for-clas.. c6be0093ae) [x86_64-darwin19] | |compare-ruby|built-ruby| |:--------|-----------:|---------:| |vm_cvar | 5.681M| 36.980M| | | -| 6.51x| ``` Benchmark.ips calling `ActiveRecord::Base.logger` from within a Rails application. ActiveRecord::Base.logger has 71 ancestors. The more ancestors a tree has, the more clear the speed increase. IE if Base had only one ancestor we'd see no improvement. This benchmark is run on a vanilla Rails application. Benchmark code: ```ruby require "benchmark/ips" require_relative "config/environment" Benchmark.ips do |x| x.report "logger" do ActiveRecord::Base.logger end end ``` Ruby 3.0 master / Rails 6.1: ``` Warming up -------------------------------------- logger 155.251k i/100ms Calculating ------------------------------------- ``` Ruby 3.0 with cvar cache / Rails 6.1: ``` Warming up -------------------------------------- logger 1.546M i/100ms Calculating ------------------------------------- logger 14.857M (± 4.8%) i/s - 74.198M in 5.006202s ``` Lastly we ran a benchmark to demonstate the difference between master and our cache when the number of modules increases. This benchmark measures 1 ancestor, 30 ancestors, and 100 ancestors. Ruby 3.0 master: ``` Warming up -------------------------------------- 1 module 1.231M i/100ms 30 modules 432.020k i/100ms 100 modules 145.399k i/100ms Calculating ------------------------------------- 1 module 12.210M (± 2.1%) i/s - 61.553M in 5.043400s 30 modules 4.354M (± 2.7%) i/s - 22.033M in 5.063839s 100 modules 1.434M (± 2.9%) i/s - 7.270M in 5.072531s Comparison: 1 module: 12209958.3 i/s 30 modules: 4354217.8 i/s - 2.80x (± 0.00) slower 100 modules: 1434447.3 i/s - 8.51x (± 0.00) slower ``` Ruby 3.0 with cvar cache: ``` Warming up -------------------------------------- 1 module 1.641M i/100ms 30 modules 1.655M i/100ms 100 modules 1.620M i/100ms Calculating ------------------------------------- 1 module 16.279M (± 3.8%) i/s - 82.038M in 5.046923s 30 modules 15.891M (± 3.9%) i/s - 79.459M in 5.007958s 100 modules 16.087M (± 3.6%) i/s - 81.005M in 5.041931s Comparison: 1 module: 16279458.0 i/s 100 modules: 16087484.6 i/s - same-ish: difference falls within error 30 modules: 15891406.2 i/s - same-ish: difference falls within error ``` Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
* Fix trivial -Wundef warningsBenoit Daloze2021-05-041-1/+1
| | | | | | * See [Feature #17752] Co-authored-by: xtkoba (Tee KOBAYASHI) <xtkoba+ruby@gmail.com>
* Remove unneeded commentS-H-GAMELINKS2021-04-231-2/+0
|
* Use rb_fstring for "defined" strings.Aaron Patterson2021-03-171-4/+0
| | | | | | We can take advantage of fstrings to de-duplicate the defined strings. This means we don't need to keep the list of defined strings on the VM (or register them as mark objects)
* Destroy VM-wise locks before freeing [Bug #15852]Nobuyoshi Nakada2021-03-091-0/+2
|
* [Fixes #17622] Mark and move the previous epPeter Zhu2021-02-121-0/+10
|
* global call-cache cache table for rb_funcall*Koichi Sasada2021-01-291-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | rb_funcall* (rb_funcall(), rb_funcallv(), ...) functions invokes Ruby's method with given receiver. Ruby 2.7 introduced inline method cache with static memory area. However, Ruby 3.0 reimplemented the method cache data structures and the inline cache was removed. Without inline cache, rb_funcall* searched methods everytime. Most of cases per-Class Method Cache (pCMC) will be helped but pCMC requires VM-wide locking and it hurts performance on multi-Ractor execution, especially all Ractors calls methods with rb_funcall*. This patch introduced Global Call-Cache Cache Table (gccct) for rb_funcall*. Call-Cache was introduced from Ruby 3.0 to manage method cache entry atomically and gccct enables method-caching without VM-wide locking. This table solves the performance issue on multi-ractor execution. [Bug #17497] Ruby-level method invocation does not use gccct because it has inline-method-cache and the table size is limited. Basically rb_funcall* is not used frequently, so 1023 entries can be enough. We will revisit the table size if it is not enough.
* Rename RubyVM::MJIT to RubyVM::JITTakashi Kokubun2021-01-131-9/+12
| | | | | | | | because the name "MJIT" is an internal code name, it's inconsistent with --jit while they are related to each other, and I want to discourage future JIT implementation-specific (e.g. MJIT-specific) APIs by this rename. [Feature #17490]
* Stop managing valid class serialsTakashi Kokubun2020-12-291-1/+0
| | | | `mjit_valid_class_serial_p` has no longer been used since b9007b6c548.
* shareable_constant_value: experimental_copyKoichi Sasada2020-12-241-3/+7
| | | | | | | "experimental_everything" makes the assigned value, it means the assignment change the state of assigned value. "experimental_copy" tries to make a deep copy and make copyied object sharable.
* Changed shareable literal semantics [Feature #17397]Nobuyoshi Nakada2020-12-231-0/+8
| | | | | | When `literal`, check if the literal about to be assigned to a constant is ractor-shareable, otherwise raise `Ractor::Error` at runtime instead of `SyntaxError`.
* Prefer stdbool in vm_execTakashi Kokubun2020-12-211-6/+6
| | | | Make the code a bit modern and consistent with some other places.
* TracePoint.new(&block) should be ractor-localKoichi Sasada2020-12-221-2/+0
| | | | | TracePoint should be ractor-local because the Proc can violate the Ractor-safe.
* Introduce Ractor::IsolationErrorKoichi Sasada2020-12-211-2/+1
| | | | | | | | | | | Ractor has several restrictions to keep each ractor being isolated and some operation such as `CONST="foo"` in non-main ractor raises an exception. This kind of operation raises an error but there is confusion (some code raises RuntimeError and some code raises NameError). To make clear we introduce Ractor::IsolationError which is raised when the isolation between ractors is violated.
* Mark active_unitsTakashi Kokubun2020-12-201-0/+2
| | | | | | | | | | | | | | | | | | to avoid SEGV on mjit_recompile and compact_all_jit_code. For some reason, ISeqs on stack are sometimes GC-ed (why?) and therefore it may run mjit_recompile on a GC-ed ISeq, which I expected d07183ec85d to fix but apparently it may refer to random things if already GC-ed. Marking active_units would workaround the situation. http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3292740 Also, while compact_all_jit_code was executed, we saw some SEGVs where CCs seemed to be already GC-ed, meaning their owner ISeq was not marked properly. Even if units are still in active_units, it's not guaranteed that their ISeqs are in use. So in this case we need to mark active_units for a legitimate reason. http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3293277 http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3293090
* Stop marking unit_queueTakashi Kokubun2020-12-201-2/+0
| | | | | | | | | | The original motivation of this marking was https://github.com/k0kubun/yarv-mjit/issues/20. As wanabe said, there are multiple options to mitigate the issue, and Eric Wong introduced another fix at 143776f6fe by checking unit->iseq inside the lock. Therefore this particular condition has been covered in two ways, and the script given by wanabe no longer crashes without mjit_mark().
* fix method cache debug toolKoichi Sasada2020-12-191-1/+0
|
* Support shareable_constant_value: literalNobuyoshi Nakada2020-12-141-0/+1
|
* Make the value shareable deeplyNobuyoshi Nakada2020-12-141-1/+1
|
* Call FrozenCore.make_shareableNobuyoshi Nakada2020-12-141-0/+7
|
* Introduce negative method cacheKoichi Sasada2020-12-141-0/+10
| | | | pCMC doesn't have negative method cache so this patch implements it.
* Removed deprecated Time#succNobuyoshi Nakada2020-12-071-1/+3
|
* fix decl of ruby_single_main_ractorKoichi Sasada2020-12-071-0/+1
| | | | | | | On windows, MJIT doesn't work without this patch because of the declaration of ruby_single_main_ractor. This patch fix this issue and move the definition of it from ractor.c to vm.c to locate near place of ruby_current_vm_ptr.
* fix initialize orderKoichi Sasada2020-12-041-1/+1
| | | | | | `captured->code.val` should be initialize before because it can be a GC point by another ractor because `RB_OBJ_WRITE` can issue VM locking.
* add GC guardKoichi Sasada2020-12-031-1/+5
| | | | | new_prev_env is stored in the env_body memory block but this is not a GC root, so new_prev_env could be freed.
* rb_ext_ractor_safe() to declare ractor-safe extKoichi Sasada2020-12-011-0/+1
| | | | | | | | | | | C extensions can violate the ractor-safety, so only ractor-safe C extensions (C methods) can run on non-main ractors. rb_ext_ractor_safe(true) declares that the successive defined methods are ractor-safe. Otherwiwze, defined methods checked they are invoked in main ractor and raise an error if invoked at non-main ractors. [Feature #17307]
* Only check if the current ep is a local or not, then markAaron Patterson2020-11-301-4/+2
| | | | | | | | | | The vm mark function should only check if the current frame is a local or not and then mark values in that frame. Since it's walking up the stack looking at each cfp, then all ep's should be examined. This fixes a bug in the Rails tests where we're seeing segv in railties. Thanks Yasuo Honda for giving me a reliable repro!
* Remove obsoleted internal/mjit.h inclusionTakashi Kokubun2020-11-221-1/+0
| | | | :bow:
* fix public interfaceKoichi Sasada2020-11-181-1/+1
| | | | | | | | | | | | | | | | | | To make some kind of Ractor related extensions, some functions should be exposed. * include/ruby/thread_native.h * rb_native_mutex_* * rb_native_cond_* * include/ruby/ractor.h * RB_OBJ_SHAREABLE_P(obj) * rb_ractor_shareable_p(obj) * rb_ractor_std*() * rb_cRactor and rm ractor_pub.h and rename srcdir/ractor.h to srcdir/ractor_core.h (to avoid conflict with include/ruby/ractor.h)
* rb_vm_add_root_module(): Remove unused parameterAlan Wu2020-11-091-1/+1
|
* Add `GC.auto_compact= true/false` and `GC.auto_compact`Aaron Patterson2020-11-021-0/+30
| | | | | | | | | | * `GC.auto_compact=`, `GC.auto_compact` can be used to control when compaction runs. Setting `auto_compact=` to true will cause compaction to occurr duing major collections. At the moment, compaction adds significant overhead to major collections, so please test first! [Feature #17176]
* Fix a typo [ci skip]Kazuhiro NISHIYAMA2020-10-301-1/+1
|
* Ractor.make_shareable(a_proc)Koichi Sasada2020-10-301-10/+90
| | | | | | | | | | | | | | | | | | | Ractor.make_shareable() supports Proc object if (1) a Proc only read outer local variables (no assignments) (2) read outer local variables are shareable. Read local variables are stored in a snapshot, so after making shareable Proc, any assignments are not affeect like that: ```ruby a = 1 pr = Ractor.make_shareable(Proc.new{p a}) pr.call #=> 1 a = 2 pr.call #=> 1 # `a = 2` doesn't affect ``` [Feature #17284]
* check isolated Proc more strictlyKoichi Sasada2020-10-291-15/+96
| | | | | Isolated Proc prohibit to access outer local variables, but it was violated by binding and so on, so they should be error.
* Dump FrozenCore speciallyNobuyoshi Nakada2020-10-201-0/+1
|
View Lorry Controller Status