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

Refactor finalize/reference processor #150

Merged
merged 12 commits into from
Oct 25, 2023

Conversation

fepicture
Copy link
Contributor

@fepicture fepicture commented Sep 26, 2023

edit v1: sync latest status, i have finish the reference processor and integrate together.
edit v2: update with binding PR link.

fix #145
mmtk-jikesrvm PR #150
jikesRVM PR mmtk/jikesrvm#16

Modifications to the mmtk-jikesrvm repository encompass three key aspects:

  1. I have removed some old bind APIs, marking them as unimplement, or directly removing them.
  2. I implemented the process_weak_ref and forward_weak_ref methods. These will be invoked in the work bucket and act as an entry point for the original process in jikesrvm.
  3. Lastly, the CI heap configuration has been updated.

All tests for the current semispace have passed. I've rebased to the draft pull request.
 Changes:
- I implemented process_weak_refs which is invoked by a workbucket to process weak references.
  Internally, it uses jtoc_call to reuse existing JikesRVM methods.
@fepicture fepicture changed the title [wip] Refactor finalize processor [wip] Refactor finalize/reference processor Sep 26, 2023
changes:
  - Refactor to use state machine style scanning
  - Remove unnecessary debugging code
@fepicture fepicture changed the title [wip] Refactor finalize/reference processor Refactor finalize/reference processor Oct 4, 2023
@fepicture fepicture marked this pull request as ready for review October 4, 2023 05:46
@fepicture
Copy link
Contributor Author

fepicture commented Oct 5, 2023

update v1: i will test in my repo action first

I just found that the ci is using GitHub ci runner, I am going to test it in my repo action.


@qinsoon thanks for your commit to update jikesrvm version.
the test suite heap usage has been tested on my local (64GiB RAM, i9-12900H), but I do not know why will fail :p

- Fix style-check
- Upgrade heap size in weak-ref and normal test
- Disable flaky test
Copy link
Collaborator

@wks wks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code should function properly, although there may be some hidden problems that prevent some tests from passing. But JikesRVM is still one of our officially-supported VMs. We run binding tests for some PRs (will soon become all PRs) of mmtk-core, and JikesRVM is one of the VMs to run binding tests with. So I think it is not appropriate to merge this unstable change and disable some tests now.

I suggest we merge your change, but keep your change disabled by default. That is, the MMTK-JikesRVM will still use the reference processors in mmtk-core. But with a compile-time flag, MMTk-JikesRVM will use JikesRVM's reference/finalizer processors, instead.

You can use conditional compilation tricks to enable/disable the code.

For Rust code, you can use Cargo features. You can add a feature, such as binding_side_ref_proc in Cargo.toml. Inside Rust source files, you can use the attribute #[cfg(feature = "binding_side_ref_proc")] to selectively enable types, functions, blocks, statements, etc. You can also use if cfg!(feature = "binding_side_ref_proc") to guard the control flow.

For Java code, you can just write if SOME_CONSTANT { ... }, and JikesRVM's compiler is smart enough to eliminate dead code. I'll discuss more in the review comments in your PR in the jikesrvm repo.

For test scripts such as ci-test-assertions.sh, instead of commenting out failing tests and changing heap sizes, I suggest copy those scripts, save to different files (such as ci-test-assertions-weakref.sh), and edit the content there, including disabling failing tests and changing heap sizes. (p.s. You should change both -Xms and -Xmx so that on each line the -Xms and -Xmx are set to the same value.)

And you should create a compile script to compile jikesrvm plus mmtk-jikesrvm using your added conditional compilation flags.

.github/scripts/ci-test-assertions.sh Outdated Show resolved Hide resolved
.github/scripts/ci-test-normal.sh Outdated Show resolved Hide resolved
jikesrvm/rvm/src/org/jikesrvm/runtime/Entrypoints.java Outdated Show resolved Hide resolved
mmtk/api/mmtk.h Show resolved Hide resolved
mmtk/src/api.rs Show resolved Hide resolved
mmtk/src/reference_glue.rs Outdated Show resolved Hide resolved
mmtk/src/scanning.rs Outdated Show resolved Hide resolved
* Add a new configuration setting. The test script has been updated to modify this configuration using `sed`.
* Employ Rust's `cfg` attribute to conditionally compile specific modules/functions.
@fepicture
Copy link
Contributor Author

hi @qinsoon, I have pushed a new commit to solve the comment

(basically, use conditional compile to keep the compatibility),

can u activate the GitHub action workflow for this new commit?
https://github.com/mmtk/mmtk-jikesrvm/actions/runs/6600465759

https://github.com/mmtk/mmtk-jikesrvm/actions/runs/6600465756

@qinsoon
Copy link
Member

qinsoon commented Oct 23, 2023

hi @qinsoon, I have pushed a new commit to solve the comment

(basically, use conditional compile to keep the compatibility),

can u activate the GitHub action workflow for this new commit? https://github.com/mmtk/mmtk-jikesrvm/actions/runs/6600465759

https://github.com/mmtk/mmtk-jikesrvm/actions/runs/6600465756

Yeah. I just did. I thought the workflows would be allowed as they were approved for the previous commit. I will keep an eye on the PR.

@fepicture
Copy link
Contributor Author

Thank you 🙇

@fepicture fepicture requested a review from wks October 23, 2023 01:17
Copy link
Collaborator

@wks wks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although not all tests passed, the current state of the code used conditional compilation and other techniques to keep the CI tests passing. In this sense, it looks good to me.

We should keep working on this feature to make it stable so that we can eventually use VM-side weak ref and finalization processing by default.

@wks
Copy link
Collaborator

wks commented Oct 24, 2023

A recent upstream change (mmtk/mmtk-core@57af17f) moved the method is_emergency_collection from Plan to GlobalState, but GlobalState is a private structure and inaccessible from the VM binding. That prevents this PR from working.

The built-in reference processors and finalization processors can access the MMTK::state field because they are parts of the mmtk crate. We should make change to mmtk-core and expose the is_emergency_collection function to the binding.

@fepicture
Copy link
Contributor Author

A recent upstream change (mmtk/mmtk-core@57af17f) moved the method is_emergency_collection from Plan to GlobalState, but GlobalState is a private structure and inaccessible from the VM binding. That prevents this PR from working.

The built-in reference processors and finalization processors can access the MMTK::state field because they are parts of the mmtk crate. We should make change to mmtk-core and expose the is_emergency_collection function to the binding.

thanks I will fix later.

github-merge-queue bot pushed a commit to mmtk/mmtk-core that referenced this pull request Oct 24, 2023
`is_emergency_collection` is useful during weak reference processing.
JVMs can choose not to retain referents of `SoftReference` during
emergency GC.
 
The `is_emergency_collection` function was moved from `Plan` to
`GlobalState` in
57af17f.
After that, the `MMTK:state` field is private and inaccessible to VM
bindings. VM bindings that depend on the to-be-deprecated built-in
`ReferenceProcessor` still work because it is part of the `mmtk` crate,
and can `mmtk.state.is_emergency_collection`. However, VM bindings that
do weak reference processing on the VM side using the
`Scanning::process_weak_refs` API can no longer call that function. This
makes [this PR](mmtk/mmtk-jikesrvm#150) unable
to merge. In the future, the OpenJDK binding will also need it when it
off-loads weak reference processing to the binding side.

This PR adds a public API function `MMTK::is_emergency_collection` which
can be called by the VM bindings.
@fepicture
Copy link
Contributor Author

hi, @qinsoon

I have pushed a new commit to update with mmtk-core PR(expose the API for check emergency collection )

Plz activate the GitHub action workflow.

@wks
Copy link
Collaborator

wks commented Oct 25, 2023

The "Dacapo Tests / test" failed with a known bug that existed before this PR was introduced. I'll rerun the test.

@wks wks merged commit d9daca2 into mmtk:master Oct 25, 2023
3 checks passed
k-sareen pushed a commit to k-sareen/mmtk-core that referenced this pull request Apr 11, 2024
`is_emergency_collection` is useful during weak reference processing.
JVMs can choose not to retain referents of `SoftReference` during
emergency GC.
 
The `is_emergency_collection` function was moved from `Plan` to
`GlobalState` in
mmtk@57af17f.
After that, the `MMTK:state` field is private and inaccessible to VM
bindings. VM bindings that depend on the to-be-deprecated built-in
`ReferenceProcessor` still work because it is part of the `mmtk` crate,
and can `mmtk.state.is_emergency_collection`. However, VM bindings that
do weak reference processing on the VM side using the
`Scanning::process_weak_refs` API can no longer call that function. This
makes [this PR](mmtk/mmtk-jikesrvm#150) unable
to merge. In the future, the OpenJDK binding will also need it when it
off-loads weak reference processing to the binding side.

This PR adds a public API function `MMTK::is_emergency_collection` which
can be called by the VM bindings.
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.

[ospp][wip] Use the new weak reference processing API for the JikesRVM binding
3 participants