summaryrefslogtreecommitdiff
path: root/variable.c
Commit message (Collapse)AuthorAgeFilesLines
* Implement Objects on VWAPeter Zhu2022-07-151-1/+7
| | | | | | This commit implements Objects on Variable Width Allocation. This allows Objects with more ivars to be embedded (i.e. contents directly follow the object header) which improves performance through better cache locality.
* Get rid of a nasal demonNobuyoshi Nakada2022-06-231-1/+1
| | | | | | On platforms not having `typeof`, `ccan_container_off_var()` macro subtracts the pointer variable from the member address pointed by that variable.
* [Bug #18813] Warn when autoload has to lookup in parent namespaceJean Boussier2022-06-181-0/+16
| | | | This is a verbose mode only warning.
* Fix Module#const_source_location for autoload constants with direct requiresJeremy Evans2022-06-061-2/+5
| | | | | | | | | | If an autoload exists for a constant, but the path for the autoload was required, const_source_location would return [false, 0] instead of the actual file and line. This fixes it by setting the appropriate file and line in rb_const_set, and saving the file and line in const_tbl_update before they get reset by current_autoload_data. Fixes [Bug #18624]
* Simplify the autoload require logic.Samuel Williams2022-05-261-36/+28
|
* Fix GC race condition in autoload.Samuel Williams2022-05-261-15/+18
|
* Tidy up redundant returns.Samuel Williams2022-05-251-3/+1
|
* Retain reference to blocking fibers.Samuel Williams2022-05-251-31/+15
|
* Fold too long lines, etc [ci skip]Nobuyoshi Nakada2022-05-191-5/+14
|
* Suppress unused-function [ci skip]Nobuyoshi Nakada2022-05-191-0/+2
|
* Move feature deletion from GC mark to `autoload_delete`. (#5912)Samuel Williams2022-05-171-6/+10
|
* Restore implicit relationship between `autoload_const` and `autoload_data` ↵Samuel Williams2022-05-171-62/+116
| | | | during GC. (#5911)
* Suppress an unused-but-set-variable warning [ci skip]Nobuyoshi Nakada2022-05-171-3/+5
|
* Delete autoload data from global features after autoload has completed. (#5910)Samuel Williams2022-05-171-251/+304
| | | | | * Update naming of critical section assertions macros. * Improved locking for autoload.
* Fix various autoload race conditions. (#5898)Samuel Williams2022-05-151-76/+128
| | | | | | | | | | | * 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.
* Use a proper mutex for autoloading features. (#5788)Samuel Williams2022-05-081-133/+100
| | | | | | Object#autoload implements a custom per-thread "mutex" for blocking threads waiting on autoloading a feature. This causes problems when used with the fiber scheduler. We swap the implementation to use a Ruby mutex which is fiber aware.
* call `const_added` after `autoload`Koichi Sasada2022-04-081-10/+21
| | | | | | | | | | | | | | | | | When calling `const_added` while process in `autoload`, it can cause synchronization issue because of a thread swithcing. http://ci.rvm.jp/logfiles/brlog.trunk.20220407-152213#L489 ``` 1) Module#autoload (concurrently) raises a LoadError in each thread if the file does not exist ERROR NameError: uninitialized constant ModuleSpecs::Autoload::FileDoesNotExist ModuleSpecs::Autoload::FileDoesNotExist ^^^^^^^^^^^^^^^^^^ /tmp/ruby/v3/src/trunk/spec/ruby/core/module/autoload_spec.rb:965:in `block (5 levels) in <top (required)>' ```
* Finer-grained constant cache invalidation (take 2)Kevin Newton2022-04-011-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | This commit reintroduces finer-grained constant cache invalidation. After 8008fb7 got merged, it was causing issues on token-threaded builds (such as on Windows). The issue was that when you're iterating through instruction sequences and using the translator functions to get back the instruction structs, you're either using `rb_vm_insn_null_translator` or `rb_vm_insn_addr2insn2` depending if it's a direct-threading build. `rb_vm_insn_addr2insn2` does some normalization to always return to you the non-trace version of whatever instruction you're looking at. `rb_vm_insn_null_translator` does not do that normalization. This means that when you're looping through the instructions if you're trying to do an opcode comparison, it can change depending on the type of threading that you're using. This can be very confusing. So, this commit creates a new translator function `rb_vm_insn_normalizing_translator` to always return the non-trace version so that opcode comparisons don't have to worry about different configurations. [Feature #18589]
* Prefix ccan headers (#4568)Nobuyoshi Nakada2022-03-301-16/+16
| | | | | | | | | | | | | * Prefixed ccan headers * Remove unprefixed names in ccan/build_assert * Remove unprefixed names in ccan/check_type * Remove unprefixed names in ccan/container_of * Remove unprefixed names in ccan/list Co-authored-by: Samuel Williams <samuel.williams@oriontransfer.co.nz>
* Revert "Finer-grained inline constant cache invalidation"Nobuyoshi Nakada2022-03-251-6/+13
| | | | | | | | | | | | This reverts commits for [Feature #18589]: * 8008fb7352abc6fba433b99bf20763cf0d4adb38 "Update formatting per feedback" * 8f6eaca2e19828e92ecdb28b0fe693d606a03f96 "Delete ID from constant cache table if it becomes empty on ISEQ free" * 629908586b4bead1103267652f8b96b1083573a8 "Finer-grained inline constant cache invalidation" MSWin builds on AppVeyor have been crashing since the merger.
* Finer-grained inline constant cache invalidationKevin Newton2022-03-241-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current behavior - caches depend on a global counter. All constant mutations cause caches to be invalidated. ```ruby class A B = 1 end def foo A::B # inline cache depends on global counter end foo # populate inline cache foo # hit inline cache C = 1 # global counter increments, all caches are invalidated foo # misses inline cache due to `C = 1` ``` Proposed behavior - caches depend on name components. Only constant mutations with corresponding names will invalidate the cache. ```ruby class A B = 1 end def foo A::B # inline cache depends constants named "A" and "B" end foo # populate inline cache foo # hit inline cache C = 1 # caches that depend on the name "C" are invalidated foo # hits inline cache because IC only depends on "A" and "B" ``` Examples of breaking the new cache: ```ruby module C # Breaks `foo` cache because "A" constant is set and the cache in foo depends # on "A" and "B" class A; end end B = 1 ``` We expect the new cache scheme to be invalidated less often because names aren't frequently reused. With the cache being invalidated less, we can rely on its stability more to keep our constant references fast and reduce the need to throw away generated code in YJIT.
* variable.c: Fix incorrect identation in `const_added`Jean Boussier2022-01-141-2/+2
|
* Add a Module#const_added callbackJean Boussier2022-01-141-0/+10
| | | | | | | | | | | | [Feature #17881] Works similarly to `method_added` but for constants. ```ruby Foo::BAR = 42 # call Foo.const_added(:FOO) class Foo::Baz; end # call Foo.const_added(:Baz) Foo.autoload(:Something, "path") # call Foo.const_added(:Something) ```
* Fix typos [ci skip]Kazuhiro NISHIYAMA2021-12-251-1/+1
|
* prohibit load by `autoload` on non-main RactorKoichi Sasada2021-12-151-0/+4
| | | | fix [Bug #18120]
* allow to access ivars of classes/modulesKoichi Sasada2021-10-231-10/+66
| | | | | if an ivar of a class/module refer to a shareable object, this ivar can be read from non-main Ractors.
* Extract yjit_force_iv_index and make it work when object is frozenAlan Wu2021-10-201-3/+30
| | | | | | | | | | | | | | | | | | In an effort to simplify the logic YJIT generates for accessing instance variable, YJIT ensures that a given name-to-index mapping exists at compile time. In the case that the mapping doesn't exist, it was created by using rb_ivar_set() with Qundef on the sample object we see at compile time. This hack isn't fine if the sample object happens to be frozen, in which case YJIT would raise a FrozenError unexpectedly. To deal with this, make a new function that only reserves the mapping but doesn't touch the object. This is rb_obj_ensure_iv_index_mapping(). This new function superceeds the functionality of rb_iv_index_tbl_lookup() so it was removed. Reported by and includes a test case from John Hawthorn <john@hawthorn.email> Fixes: GH-282
* Remove autoload for constant if the autoload failsJeremy Evans2021-10-081-16/+22
| | | | | | | | | | | | | Previously, if an autoload failed (the file was loaded, but the constant was not defined by the autoloaded file). Ruby will try to autoload again if you delete the autoloaded file from $LOADED_FEATURES. With this change, the autoload and the constant itself are removed as soon as it fails. To handle cases where multiple threads are autoloading, when deleting an autoload, handle the case where another thread already deleted it. Fixes [Bug #15790]
* Merge if statementS-H-GAMELINKS2021-10-071-4/+1
|
* Return fstrings from `build_const_pathname`.Samuel Williams2021-09-251-2/+1
| | | | | | It's possible for `build_const_pathname` to be called when `rb_cString` is still NULL. There is a fix-up step when `rb_cString` is initialized, but it only applies to `fstring` instances.
* Refactor and Using RBOOL macroS.H2021-09-151-6/+2
|
* Use Module#ancestors order in recursive constant lookupAlan Wu2021-06-301-5/+19
| | | | | | | | | | | | | | | | | | | | | Before this commit, const_get with inherit=true and constant lookup expressions searched the ancestors of the starting point in an order different from `starting_point.ancestors`. Items in the ancestry list introduced through prepend were searched after searching the module they were prepended into. This oddity allowed for situations where constant lookups gave different results even though `starting_point.ancestors` is the same. Do the lookup in the same order as `starting_point.ancestors` by skipping classes and modules that have an origin iclass. The origin iclass is in the super chain after the prepended modules. Note that just like before this commit, the starting point of the constant lookup is always the first item that we search, regardless of the presence of any prepended modules. [Bug #17887]
* Get rid of pointer castingNobuyoshi Nakada2021-06-231-29/+34
|
* Refactor class variable cache functionsNobuyoshi Nakada2021-06-231-2/+5
| | | | | | | Extracted repeated code as update_classvariable_cache. When cvc table is not set in getclassvariable, an empty table was created but it has no id and would cause [BUG], so made the code same as setclassvariable.
* Add a cache for class variableseileencodes2021-06-181-8/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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
* Refactor rb_class_path_cached function (#4485)S.H2021-06-011-2/+1
|
* Refactor rb_define_class_variable function (#4492)S.H2021-06-011-2/+1
|
* Revert "Filling cache values on cvar write"Aaron Patterson2021-05-111-84/+8
| | | | | This reverts commit 08de37f9fa3469365e6b5c964689ae2bae0eb9f3. This reverts commit e8ae922b62adb00a80d3d4c49f7d7b0e6026eaba.
* Filling cache values on cvar writeeileencodes2021-05-111-0/+19
| | | | | | Instead of on read. Once it's in the inline cache we never have to make one again. We want to eventually put the value into the cache, and the best opportunity to do that is when you write the value.
* Add a cache for class variableseileencodes2021-05-111-8/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Refactor `rb_class_ivar_set`eileencodes2021-03-101-7/+4
| | | | | | In every caller of `rb_class_ivar_set` it checks for the `RCLASS_IV_TBL` and then creates it if it doesn't exist. Instead of repeating this in every caller, this can be done once in `rb_class_ivar_set`.
* Revert "Don't pin `val` passed in to `rb_define_const`."Aaron Patterson2021-02-031-0/+1
| | | | | | I think this is breaking something This reverts commit 1be84e53d76cff30ae371f0b397336dee934499d.
* Don't pin `val` passed in to `rb_define_const`.Aaron Patterson2021-02-031-1/+0
| | | | | The caller should be responsible for holding a pinned reference (if they need that)
* Skip freezing check on setting temporary class path [Bug #17563]Nobuyoshi Nakada2021-01-201-1/+1
| | | | Co-authored-by: ryannevell (Ryan Nevell) <ryan.nevell@gmail.com>
* Replace "iff" with "if and only if"Gannon McGibbon2021-01-191-1/+1
| | | | | | | iff means if and only if, but readers without that knowledge might assume this to be a spelling mistake. To me, this seems like exclusionary language that is unnecessary. Simply using "if and only if" instead should suffice.
* Introduce Ractor::IsolationErrorKoichi Sasada2020-12-211-9/+8
| | | | | | | | | | | 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.
* sync RCLASS_CONST_TBL()Koichi Sasada2020-12-201-29/+62
| | | | | RCLASS_CONST_TBL() is shared resource so we need to sync with other ractors.
* Use category: :deprecated in warnings that are related to deprecationJeremy Evans2020-12-181-2/+2
| | | | | | | | | | | | | | | | | Also document that both :deprecated and :experimental are supported :category option values. The locations where warnings were marked as deprecation warnings was previously reviewed by shyouhei. Comment a couple locations where deprecation warnings should probably be used but are not currently used because deprecation warning enablement has not occurred at the time they are called (RUBY_FREE_MIN, RUBY_HEAP_MIN_SLOTS, -K). Add assert_deprecated_warn to test assertions. Use this to simplify some tests, and fix failing tests after marking some warnings with deprecated category.
* tuning ivar setKoichi Sasada2020-12-161-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * make rb_init_iv_list() simple * introduce vm_setivar_slowpath() for cache miss cases ../clean/miniruby is 647ee6f091. Calculating ------------------------------------- ./miniruby ../clean/miniruby ../ruby_2_7/miniruby vm_ivar_init 7.388M 6.814M 5.771M i/s - 30.000M times in 4.060420s 4.402534s 5.198781s vm_ivar_init_subclass 2.158M 2.147M 1.974M i/s - 3.000M times in 1.390328s 1.397587s 1.519951s vm_ivar_set 128.607M 97.931M 140.668M i/s - 30.000M times in 0.233269s 0.306338s 0.213268s vm_ivar 144.315M 151.722M 117.734M i/s - 30.000M times in 0.207879s 0.197730s 0.254811s Comparison: vm_ivar_init ./miniruby: 7388398.8 i/s ../clean/miniruby: 6814257.1 i/s - 1.08x slower ../ruby_2_7/miniruby: 5770583.9 i/s - 1.28x slower vm_ivar_init_subclass ./miniruby: 2157763.6 i/s ../clean/miniruby: 2146557.0 i/s - 1.01x slower ../ruby_2_7/miniruby: 1973747.9 i/s - 1.09x slower vm_ivar_set ../ruby_2_7/miniruby: 140668063.8 i/s ./miniruby: 128606912.1 i/s - 1.09x slower ../clean/miniruby: 97931027.8 i/s - 1.44x slower vm_ivar ../clean/miniruby: 151722121.9 i/s ./miniruby: 144314526.5 i/s - 1.05x slower ../ruby_2_7/miniruby: 117734305.5 i/s - 1.29x slower
View Lorry Controller Status