-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make gc_mark_ptr have a single responsibility
Currently the GC's marking functions functions (gc_mark, gc_mark_ptr, gc_mark_children) are responsible for both marking and object tracing. This becomes awkward when we need to use object tracing for non-GC related purposes (such as dumping the heap). The current implementation relies on `gc_mark_ptr` having multiple responsibilites depending on whether it's being called during GC or during mutator work - it switches based on `objspace->flags.during_gc`. If that flag is set it runs marking, and if not it passes the pointer in question to `reachable_objects_from_callback`, which then looks at the current ractor for a function pointer to execute with the pointer as an argument. This PR removes the conditional from `gc_mark_ptr`. Making it unconditionally mark the pointer. It then pre-configures each ractor to use `gc_mark_ptr` as it's default mark function pointer, and replaces previous calls to `gc_mark_ptr` with calls to `reachable_objects_from_callback` - essentially unifying the two approaces to object tracing - In order to walk the object graph we now need to do the same steps: 1. make sure there is a function pointer attached to the ractor 2. use the iterator function `reachable_objects_from_callback` One of the challenges involved in walking the object graph, is that we cannot change the api for marking T_DATA objects. The nice thing about the original approach, is that we didn't have to - all marking callbacks in C extension objects will eventually use gc_mark_ptr - because it's used by `rb_gc_mark` which is part of the public API. This new approach also doesn't require changing the public API. We implement `rb_gc_mark` on top of `reachable_objects_from_callback` and no user facing changes have to be made to any code in C extensions. This new approach is the first step in separating gc marking from object graph traversal. This is necessary for us to start implementing alternate GC's so that we can implement custom marking and tracing functions independantly.
- Loading branch information
1 parent
f602cb5
commit 2ea6d35
Showing
4 changed files
with
50 additions
and
36 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters