aboutsummaryrefslogtreecommitdiffstats
path: root/variable.c
Commit message (Collapse)AuthorAgeFilesLines
* Free everything at shutdownAdam Hess2023-12-071-0/+27
| | | | | | | when the RUBY_FREE_ON_SHUTDOWN environment variable is set, manually free memory at shutdown. Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org> Co-authored-by: Peter Zhu <peter@peterzhu.ca>
* Fix incorrect "nested_fake_name" documentation. (#9135)Samuel Williams2023-12-061-1/+1
|
* Fix parameter types for rb_ivar_foreach() callbacksAlan Wu2023-12-051-6/+4
| | | | | | | | For this public API, the callback is declared to take `(ID, VALUE, st_data_t)`, but it so happens that using `(st_data_t, st_data_t, st_data_t)` also type checks, because the underlying type is identical. Use it as declared and get rid of some casts.
* Make rb_obj_copy_ivs_to_hash_table_i staticPeter Zhu2023-12-041-1/+1
|
* Fix indentation in ivar_set [ci skip]Peter Zhu2023-11-281-2/+2
|
* Fix compaction for generic ivarsPeter Zhu2023-11-241-3/+20
| | | | | | When generic instance variable has a shape, it is marked movable. If it it transitions to too complex, it needs to update references otherwise it may have incorrect references.
* Fix compacting during evacuation of generic ivarsPeter Zhu2023-11-231-2/+20
| | | | | | | When evacuating generic instance variables, the instance variables exist in both the array and the ST table. We need to ensure it has switched to the ST table before performing any operations that can trigger GC compaction.
* Use count macros for counting instance variablesAaron Patterson2023-11-211-33/+2
| | | | | We don't need to check for Qundef because the shape tells us the number if IVs that are stored on the object
* Fix memory leak when evacuating generic ivarsPeter Zhu2023-11-211-1/+1
| | | | | | The lookup in the table is using the wrong key when converting generic instance variables to too complex, which means that it never looks up the entry which leaks memory when the entry is overwritten.
* Don't try compacting ivars on Classes that are "too complex"Aaron Patterson2023-11-201-16/+0
| | | | | Too complex classes use a hash table to store ivs, and should always pin their IVs. We shouldn't touch those classes in compaction.
* Fix crash when evacuating generic ivarPeter Zhu2023-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When transitioning generic instance variable objects to too complex, we set the shape first before performing inserting the new gen_ivtbl. The st_insert for the new gen_ivtbl could allocate and cause a GC. If that happens, then it will crash because the object will have a too complex shape but not yet be backed by a st_table. This commit changes the order so that the insert happens first before the new shape is set. The following script reproduces the issue: ``` o = [] o.instance_variable_set(:@a, 1) i = 0 o = Object.new while RubyVM::Shape.shapes_available > 0 o.instance_variable_set(:"@i#{i}", 1) i += 1 end ary = 1_000.times.map { [] } GC.stress = true ary.each do |o| o.instance_variable_set(:@a, 1) o.instance_variable_set(:@b, 1) end ```
* Fix indentation [ci skip]Peter Zhu2023-11-201-26/+26
|
* Fix crash when iterating over generic ivarsPeter Zhu2023-11-201-1/+1
|
* Refactor rb_obj_evacuate_ivs_to_hash_tableJean Boussier2023-11-171-40/+50
| | | | | | | | | | | | | | | | | | That function is a bit too low level to called from multiple places. It's always used in tandem with `rb_shape_set_too_complex` and both have to know how the object is laid out to update the `iv_ptr`. So instead we can provide two higher level function: - `rb_obj_copy_ivs_to_hash_table` to prepare a `st_table` from an arbitrary oject. - `rb_obj_convert_to_too_complex` to assign the new `st_table` to the old object, and safely free the old `iv_ptr`. Unfortunately both can't be combined into one, because `rb_obj_copy_ivar` need `rb_obj_copy_ivs_to_hash_table` to copy from one object to another.
* rb_evict_ivars_to_hash: get rid of the sahpe paramaterJean Boussier2023-11-161-7/+7
| | | | | | | | | | It's only used to allocate the table with the right size, but in some case we were passing `rb_shape_get_shape_by_id(SHAPE_OBJ_TOO_COMPLEX)` which `next_iv_index` is a bit undefined. So overall we're better to just allocate a table the size of the existing object, it should be close enough in the vast majority of cases, and that's already a de-optimizaton path anyway.
* Revert "Revert "Remove SHAPE_CAPACITY_CHANGE shapes""Peter Zhu2023-11-131-2/+1
| | | | This reverts commit 5f3fb4f4e397735783743fe52a7899b614bece20.
* [ci skip] Fix indentation in rb_class_ivar_setPeter Zhu2023-11-101-1/+1
|
* Revert "Remove SHAPE_CAPACITY_CHANGE shapes"Peter Zhu2023-11-101-1/+2
| | | | | | | This reverts commit f6910a61122931e4193bcc0fad18d839c319b720. We're seeing crashes in the test suite of Shopify's core monolith after this change.
* Remove SHAPE_CAPACITY_CHANGE shapesPeter Zhu2023-11-091-2/+1
| | | | | We don't need to create a shape to transition capacity as we can transition the capacity when the capacity of the SHAPE_IVAR changes.
* Refactor rb_shape_transition_shape_capa outJean Boussier2023-11-081-42/+13
| | | | | | | | | | | | | | | | Right now the `rb_shape_get_next` shape caller need to first check if there is capacity left, and if not call `rb_shape_transition_shape_capa` before it can call `rb_shape_get_next`. And on each of these it needs to checks if we got a TOO_COMPLEX back. All this logic is duplicated in the interpreter, YJIT and RJIT. Instead we can have `rb_shape_get_next` do the capacity transition when needed. The caller can compare the old and new shapes capacity to know if resizing is needed. It also can check for TOO_COMPLEX only once.
* Remove rb_complex_ivar_setPeter Zhu2023-11-061-36/+0
|
* Use general_ivar_set for generic ivarsPeter Zhu2023-11-061-44/+76
|
* Use general_ivar_set for Class ivarsPeter Zhu2023-11-061-49/+42
|
* Use general_ivar_set for ObjectsPeter Zhu2023-11-061-45/+35
|
* Implement general_ivar_setPeter Zhu2023-11-061-0/+77
|
* generic_ivar_set: properly check for TOO_COMPLEX on capacity transitionJean Boussier2023-11-061-1/+1
|
* Fix typo in variable.cPeter Zhu2023-11-031-1/+1
|
* Use RB_OBJ_WRITE over RB_OBJ_WRITTEN in variable.cPeter Zhu2023-11-031-4/+2
|
* Use shape capacity transitions for generic ivarsPeter Zhu2023-11-031-91/+63
| | | | | This commit changes generic ivars to respect the capacity transition in shapes rather than growing the capacity independently.
* rb_ivar_defined: handle complex modulesJean Boussier2023-11-031-1/+21
| | | | It was assuming only objects can be complex.
* Use shape capacity transition for class ivarsPeter Zhu2023-11-021-25/+31
| | | | | This commit changes class ivars to respect the capacity transition in shapes rather than growing the capacity independently.
* Make every initial size pool shape a root shapePeter Zhu2023-11-021-2/+1
| | | | | This commit makes every initial size pool shape a root shape and assigns it a capacity of 0.
* Fix write barrier in rb_copy_generic_ivarPeter Zhu2023-11-021-1/+1
|
* Remove duplicated code in generic_ivar_setPeter Zhu2023-11-021-5/+0
| | | | There is a duplicated check for the object is too complex.
* Fix remove_class_variable for too complex classesPeter Zhu2023-11-011-58/+33
|
* Refactor rb_obj_remove_instance_variablePeter Zhu2023-11-011-32/+25
|
* Optimize for too complex objectsPeter Zhu2023-11-011-2/+4
|
* remove_instance_variable: Handle running out of shapesJean Boussier2023-11-011-12/+13
| | | | | | | | `remove_shape_recursive` wasn't considering that if we run out of shapes, it might have to transition to SHAPE_TOO_COMPLEX. When this happens, we now return with an error and the caller initiates the evacuation.
* Fix removing non-existent ivar for too complexPeter Zhu2023-11-011-2/+6
|
* Fix remove_instance_variable for too complex generic ivarPeter Zhu2023-10-311-1/+9
|
* Fix remove_instance_variable for too complex classPeter Zhu2023-10-311-1/+6
|
* Add ST table to gen_ivtbl for complex shapesPeter Zhu2023-10-311-77/+100
| | | | | | | On 32-bit systems, we must store the shape ID in the gen_ivtbl to not lose the shape. If we directly store the ST table into the generic ivar table, then we lose the shape. This makes it impossible to determine the shape of the object and whether it is too complex or not.
* Create table for too complex generic variablesPeter Zhu2023-10-311-2/+5
|
* Fix "too complex" iv sets on generic ivar objectsAaron Patterson2023-10-311-0/+6
| | | | | | | | | We weren't taking in to account that objects with generic IV tables could go "too complex" in the IV set code. This commit takes that in to account and also ensures FL_EXIVAR is set when a geniv object transitions to "too complex" Co-Authored-By: Jean Boussier <byroot@ruby-lang.org>
* Handle SHAPE_TOO_COMPLEX in `generic_ivar_set`Jean Boussier2023-10-311-0/+5
|
* `get_next_shape_internal` should always return a shapeAaron Patterson2023-10-241-2/+2
| | | | | If it runs out of shapes, or new variations aren't allowed, it will return "too complex"
* geniv objects can become too complexAaron Patterson2023-10-241-61/+117
|
* remove IV limit / support complex shapes on classesAaron Patterson2023-10-241-61/+151
|
* Refactor rb_shape_transition_shape_capa to not accept capacityJean Boussier2023-10-101-6/+3
| | | | | This way the groth factor is encapsulated, which allows rb_shape_transition_shape_capa to be smarter about ideal sizes.
* Refactor rb_ensure_iv_list_sizePeter Zhu2023-08-211-19/+3
| | | | | We don't really need obj_ivar_heap_alloc and obj_ivar_heap_realloc since they're just one liners.
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-16 20:44:51 +0000