Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge with upstream and update deps (2025-02-10) #121

Merged
merged 4 commits into from
Feb 11, 2025

Conversation

wks
Copy link
Collaborator

@wks wks commented Feb 11, 2025

This PR updates the revision of mmtk-core, ruby and deps. The ruby repo is merged with the master branch in the upstream.

In the ruby repo, the upstream changed the way it updates GIVTBL. They now forward GIVTBL entries in bulk when updating weak tables. We stick to the old way of forwarding entries when scanning an object.

We also removed the HAS_MOVED_GIVTBL bit from the hidden header. Now we use a simpler strategy. We first load from the global generic_iv_tbl_ and, if not found, load from the moved_givtbl table in the Rust part of the binding.

wks added 4 commits February 11, 2025 15:02
The upstream changed its way of updating GIVTBL.  Now it no longer
updates generic ivars in gc_update_object_reference, but instead do so
for all entries in generic_iv_tbl_ in bulk during weak table updating
phase.  We still stick to the old method.  In the
dev/mmtk-overrides-default branch of the mmtk/ruby repo, we will still
use the old way, i.e. tracing and forwarding generic ivars when scanning
an object, when using MMTk.  No change in the Rust part of the code
(i.e. this repo) is needed.
We no longer use the HAS_MOVED_GIVTBL bit in the hidden header.  Now
when we try to get the givtbl of a potentially moved object, we first
look up the global general_iv_tbl_ and, if not found, look up the
RubyBinding::moved_givtbl table in the Rust part of the binding.

There is an associated change in the C part of the binding.  It now
calls mmtk_hidden_header_is_sane for sanity check.
In addition to `mmtk_{disable,enable}_collection`, we also expose an API
`mmtk_is_collection_enabled` for the Ruby runtime to implement
`GC.disable` and `GC.enable`.

We also expose the `force` and `exhaustive` parameters of
`MMTK::handle_user_collection_request` to the C part so that `GC.start`
can force a GC even when the user disabled GC.
@wks
Copy link
Collaborator Author

wks commented Feb 11, 2025

The test case TestGc#test_gc_disabled_start failed because GC.disable and GC.enable were not implemented. Consequently, an allocation triggered GC when GC should be disabled, and the GC count was wrong.

[1/1] TestGc#test_gc_disabled_start[2025-02-11T09:08:25Z INFO  mmtk::mmtk] User triggering collection
[2025-02-11T09:08:25Z INFO  mmtk::scheduler::scheduler] End of GC (2353/2388 pages, took 60 ms)
[2025-02-11T09:08:25Z INFO  mmtk::mmtk] User triggering collection
[2025-02-11T09:08:25Z INFO  mmtk::scheduler::scheduler] End of GC (2353/2366 pages, took 57 ms)
[2025-02-11T09:08:25Z INFO  mmtk::util::heap::gc_trigger] [POLL] ms: Triggering collection (2369/2366 pages)
[2025-02-11T09:08:25Z INFO  mmtk::scheduler::scheduler] End of GC (2353/5483 pages, took 55 ms)
 = 0.20 s

  1) Failure:
TestGc#test_gc_disabled_start [/home/wks/projects/mmtk-github/ruby/test/ruby/test_gc.rb:790]:
<1> expected but was
<2>.

I have implemented GC.disable and GC.enabled, and fixed GC.start to let it force a GC even when GC is disabled.

@wks wks merged commit c231732 into mmtk:master Feb 11, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant