summaryrefslogtreecommitdiff
path: root/variable.c
AgeCommit message (Collapse)Author
2021-10-23allow to access ivars of classes/modulesKoichi Sasada
if an ivar of a class/module refer to a shareable object, this ivar can be read from non-main Ractors. Notes: Merged: https://github.com/ruby/ruby/pull/5006
2021-10-20Extract yjit_force_iv_index and make it work when object is frozenAlan Wu
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
2021-10-08Remove autoload for constant if the autoload failsJeremy Evans
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] Notes: Merged: https://github.com/ruby/ruby/pull/4715 Merged-By: jeremyevans <code@jeremyevans.net>
2021-10-07Merge if statementS-H-GAMELINKS
Notes: Merged: https://github.com/ruby/ruby/pull/4939
2021-09-25Return fstrings from `build_const_pathname`.Samuel Williams
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. Notes: Merged: https://github.com/ruby/ruby/pull/4892
2021-09-15Refactor and Using RBOOL macroS.H
Notes: Merged: https://github.com/ruby/ruby/pull/4837 Merged-By: nobu <nobu@ruby-lang.org>
2021-06-30Use Module#ancestors order in recursive constant lookupAlan Wu
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] Notes: Merged: https://github.com/ruby/ruby/pull/4585
2021-06-23Get rid of pointer castingNobuyoshi Nakada
2021-06-23Refactor class variable cache functionsNobuyoshi Nakada
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.
2021-06-18Add a cache for class variableseileencodes
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> Notes: Merged: https://github.com/ruby/ruby/pull/4544
2021-06-17Adjust styles [ci skip]Nobuyoshi Nakada
* --braces-after-func-def-line * --dont-cuddle-else * --procnames-start-lines * --space-after-for * --space-after-if * --space-after-while
2021-06-01Refactor rb_class_path_cached function (#4485)S.H
Notes: Merged-By: k0kubun <takashikkbn@gmail.com>
2021-06-01Refactor rb_define_class_variable function (#4492)S.H
Notes: Merged-By: k0kubun <takashikkbn@gmail.com>
2021-05-11Revert "Filling cache values on cvar write"Aaron Patterson
This reverts commit 08de37f9fa3469365e6b5c964689ae2bae0eb9f3. This reverts commit e8ae922b62adb00a80d3d4c49f7d7b0e6026eaba.
2021-05-11Filling cache values on cvar writeeileencodes
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. Notes: Merged: https://github.com/ruby/ruby/pull/4340
2021-05-11Add a cache for class variableseileencodes
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> Notes: Merged: https://github.com/ruby/ruby/pull/4340
2021-03-10Refactor `rb_class_ivar_set`eileencodes
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`. Notes: Merged: https://github.com/ruby/ruby/pull/4254
2021-02-03Revert "Don't pin `val` passed in to `rb_define_const`."Aaron Patterson
I think this is breaking something This reverts commit 1be84e53d76cff30ae371f0b397336dee934499d.
2021-02-03Don't pin `val` passed in to `rb_define_const`.Aaron Patterson
The caller should be responsible for holding a pinned reference (if they need that) Notes: Merged: https://github.com/ruby/ruby/pull/4144
2021-01-20Skip freezing check on setting temporary class path [Bug #17563]Nobuyoshi Nakada
Co-authored-by: ryannevell (Ryan Nevell) <ryan.nevell@gmail.com> Notes: Merged: https://github.com/ruby/ruby/pull/4101
2021-01-19Replace "iff" with "if and only if"Gannon McGibbon
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. Notes: Merged: https://github.com/ruby/ruby/pull/4035
2020-12-21Introduce Ractor::IsolationErrorKoichi Sasada
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. Notes: Merged: https://github.com/ruby/ruby/pull/3957
2020-12-20sync RCLASS_CONST_TBL()Koichi Sasada
RCLASS_CONST_TBL() is shared resource so we need to sync with other ractors. Notes: Merged: https://github.com/ruby/ruby/pull/3944
2020-12-18Use category: :deprecated in warnings that are related to deprecationJeremy Evans
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. Notes: Merged: https://github.com/ruby/ruby/pull/3917
2020-12-16tuning ivar setKoichi Sasada
* 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 Notes: Merged: https://github.com/ruby/ruby/pull/3912
2020-12-12fix ivar with shareable objects issueKoichi Sasada
Instance variables of sharable objects are accessible only from main ractor, so we need to check it correctly. Notes: Merged: https://github.com/ruby/ruby/pull/3887
2020-12-10Remove the uninitialized instance variable verbose mode warningJeremy Evans
This speeds up all instance variable access, even when not in verbose mode. Uninitialized instance variable warnings were rarely helpful, and resulted in slower code if you wanted to avoid warnings when run in verbose mode. Implements [Feature #17055] Notes: Merged: https://github.com/ruby/ruby/pull/3879
2020-11-18fix public interfaceKoichi Sasada
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) Notes: Merged: https://github.com/ruby/ruby/pull/3775
2020-11-10refactoring.Koichi Sasada
iv_index_tbl_newsize() usually returns iv_index_tbl->num_entries because ivup->iv_extended is usually false.
2020-11-09eagerly initialize ivar table when index is small enoughAaron Patterson
When the inline cache is written, the iv table will contain an entry for the instance variable. If we get an inline cache hit, then we know the iv table must contain a value for the index written to the inline cache. If the index in the inline cache is larger than the list on the object, but *smaller* than the iv index table on the class, then we can just eagerly allocate the iv list to be the same size as the iv index table. This avoids duplicate work of checking frozen as well as looking up the index for the particular instance variable name. Notes: Merged: https://github.com/ruby/ruby/pull/3740
2020-11-04Simplify setting instance variablesAaron Patterson
Since T_OBJECT objects come to life as embedded objects, that means that ROBJECT_NUMIV will always return a _minimum_ of ROBJECT_EMBED_LEN_MAX. If ivup.index is *greater* than ROBJECT_NUMIV, then we know that the object *must not* be an embedded object. Thus we can skip the ROBJECT_EMBED_LEN_MAX check as well as initializing internals of embedded objects. Notes: Merged: https://github.com/ruby/ruby/pull/3734
2020-11-02suppport Ractor.send(move: true) for more detaKoichi Sasada
This patch allows to move more data types. Notes: Merged: https://github.com/ruby/ruby/pull/3727
2020-10-25Fix bootstrap-test error in previous commitJeremy Evans
2020-10-22allow to access ivars of frozen shareable objectsKoichi Sasada
Accessing a shareable object is prohibitted because it can cause race condition, but if the shareable object is frozen, there is no problem to access ivars.
2020-10-21check main-ractor or not firstKoichi Sasada
On non-multi-ractor-mode, the cost of rb_ractor_main_p() is low so check it first. Notes: Merged: https://github.com/ruby/ruby/pull/3682
2020-10-17sync RClass::ext::iv_index_tblKoichi Sasada
iv_index_tbl manages instance variable indexes (ID -> index). This data structure should be synchronized with other ractors so introduce some VM locks. This patch also introduced atomic ivar cache used by set/getinlinecache instructions. To make updating ivar cache (IVC), we changed iv_index_tbl data structure to manage (ID -> entry) and an entry points serial and index. IVC points to this entry so that cache update becomes atomically. Notes: Merged: https://github.com/ruby/ruby/pull/3662
2020-10-14sync generic_ivtblKoichi Sasada
generic_ivtbl is a process global table to maintain instance variables for non T_OBJECT/T_CLASS/... objects. So we need to protect them for multi-Ractor exection. Hint: we can make them Ractor local for unshareable objects, but now it is premature optimization. Notes: Merged: https://github.com/ruby/ruby/pull/3655
2020-09-03Introduce Ractor mechanism for parallel executionKoichi Sasada
This commit introduces Ractor mechanism to run Ruby program in parallel. See doc/ractor.md for more details about Ractor. See ticket [Feature #17100] to see the implementation details and discussions. [Feature #17100] This commit does not complete the implementation. You can find many bugs on using Ractor. Also the specification will be changed so that this feature is experimental. You will see a warning when you make the first Ractor with `Ractor.new`. I hope this feature can help programmers from thread-safety issues. Notes: Merged: https://github.com/ruby/ruby/pull/3365
2020-09-03Don't call to_s in const_setAlan Wu
Follow up for 5e16857315bf55307c5fc887ca6f03bfa0630a93. Calling a method in the middle of const_set adds a way that it would fail. It also makes it inconsistent with declaring a constant using `::`, which doesn't call `to_s`. Notes: Merged: https://github.com/ruby/ruby/pull/3509
2020-09-02Fix constant names set using const_set on a singleton classMarc-Andre Lafortune
Fixes [Bug #14895] Notes: Merged: https://github.com/ruby/ruby/pull/3502
2020-08-19ROBJECT_IV_INDEX_TBL: convert into an inline function卜部昌平
Former ROBJECT_IV_INDEX_TBL macro included RCLASS_IV_INDEX_TBL, which is not disclosed to extension libraies. The macro was kind of broken. Why not just deprecate it, and convert the internal use into an inline function. Notes: Merged: https://github.com/ruby/ruby/pull/3427
2020-08-17Ensure the shortcut cached in the classNobuyoshi Nakada
As well as the other places using RCLASS_IV_INDEX_TBL. `IO#reopen` seems the only case that the class of an object can be changed.
2020-08-02Improve docs for Module#remove_class_variable [ci skip]Alan Wu
2020-07-20Remove trailing spaces [ci skip]Nobuyoshi Nakada
2020-07-03Use ID instead of GENTRY for gvars. (#3278)Koichi Sasada
Use ID instead of GENTRY for gvars. Global variables are compiled into GENTRY (a pointer to struct rb_global_entry). This patch replace this GENTRY to ID and make the code simple. We need to search GENTRY from ID every time (st_lookup), so additional overhead will be introduced. However, the performance of accessing global variables is not important now a day and this simplicity helps Ractor development. Notes: Merged-By: ko1 <ko1@atdot.net>
2020-06-29add UNREACHABLE_RETURN卜部昌平
Not every compilers understand that rb_raise does not return. When a function does not end with a return statement, such compilers can issue warnings. We would better tell them about reachabilities. Notes: Merged: https://github.com/ruby/ruby/pull/3247
2020-06-29rb_mod_remove_cvar: do not goto into a branch卜部昌平
I'm not necessarily against every goto in general, but jumping into a branch is definitely a bad idea. Better refactor. Notes: Merged: https://github.com/ruby/ruby/pull/3247
2020-06-29rb_copy_generic_ivar: do not goto into a branch卜部昌平
I'm not necessarily against every goto in general, but jumping into a branch is definitely a bad idea. Better refactor. Notes: Merged: https://github.com/ruby/ruby/pull/3247
2020-06-29generic_ivar_update: do not goto into a branch卜部昌平
I'm not necessarily against every goto in general, but jumping into a branch is definitely a bad idea. Better refactor. Notes: Merged: https://github.com/ruby/ruby/pull/3247
2020-06-29rb_path_to_class: do not goto into a branch卜部昌平
I'm not necessarily against every goto in general, but jumping into a branch is definitely a bad idea. Better refactor. Notes: Merged: https://github.com/ruby/ruby/pull/3247
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 06:32:58 +0000