Skip to content

Document supported platforms #1431

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.

Sign up for GitHub

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

Merged
wks merged 2 commits into from
Dec 9, 2025
Merged

Document supported platforms #1431

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
35371e9
Document support tiers
wks Dec 8, 2025
641e86b
Fix to address comments
wks Dec 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,34 @@ latest Rust toolchain rather than relying on an outdated version of Rust.
Note, however, that we may switch to a more conservative MSRV policy in the future when MMTk reaches
a stable state.

## Supported platforms

Like [Rust platform support tiers][rustps], supports for MMTk core on different platforms (targets) are organized into three tiers.

- Tier 1 platforms are guaranteed to work.
- Tier 2 platforms are guaranteed to build.
- Tier 3 platforms have support in the mmtk-core code base, but we make no guarantee whether they will build or work.
Copy link
Member

@qinsoon qinsoon Dec 8, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

After more thoughts on this, I think we could just adopt Rust's tiers: T1 = 'guarantee to work' (not requiring at least one binding), T2 = 'guarantee to build' (not requiring pass CI tests), T3 = 'we have support, but no guarantee'.

Currently there is inconsistency in the current tier 2 definition: 'guarantee to build', and 'pass CI tests'. Those are two different things. Rust's T2 allows tests to fail. In the future, we will expect mmtk-core's unit tests to be more complex, as seen in #1408. I would expect 'passing tests' to be closer to 'guarantee to work' (instead of 'guarantee to build').

We may change the tier for a platform in the future, but we don't generally want to change the definition of tiers. Having 'at least one binding' is important for now, but it may become less important in the future when we have more unit tests for MMTk core, and what one binding may test eventually may become a strict subset of what our unit tests cover in MMTk core. Consider two cases. For OpenJDK, we already knew that it only tests the default space and the large object space. Eventually when we have more complex unit tests, we would expect passing CI tests to be more credible than having one binding. For JikesRVM, it only includes a subset of MMTk GC plans. I don't really feel it gives us more confidence in the platform than what the current unit testing delivers. Plus, porting MMTk core to a new platform (especially to a different architecture) should be easier than porting a binding to a new platform. We may have a platform that we could pass all the tests with good code coverage, but we don't have a real binding that targets it. Do we still put the platform as T2 because we don't have a binding to work on it (even if the unit tests may already have more coverage)?

If we really want to show the importance of having a real binding for the platform, we could add a T0 on top of T1/2/3 (which are the same as Rust's tiers): T0 requires at least one binding. In this case, T0 highlights the existence of a real binding being tested with the platform, but T1 also means we expect MMTk to work on the platform.

Copy link
Collaborator Author

@wks wks Dec 9, 2025

Choose a reason for hiding this comment

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

I removed CI and bindings from the definition of tiers. I think that should be enough for the user, and we leave some room for us to change our CI policy as we need.


Here is a list of supported platforms.

| Platform | Rust tier | MMTk tier | Notes |
|-----------------------------|-----------|-----------|-------|
| x86_64-unknown-linux-gnu | 1 | 1 | |
| i686-unknown-linux-gnu | 1 | 1 | |
| x86_64-apple-darwin | 2 | 2 | (1) |
| aarch64-unknown-linux-gnu | 1 | 3 | |
| riscv64gc-unknown-linux-gnu | 2 | 3 | |
| aarch64-linux-android | 2 | 3 | |
| x86_64-linux-android | 2 | 3 | |

Notes:
Copy link
Member

@qinsoon qinsoon Dec 8, 2025

Choose a reason for hiding this comment

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

I think we can remove the notes from README.md to keep README succinct. The notes are basically the reasons why we put them in this tier, and we only need to let users know the tiers (rather than the reasons). We can create another doc docs/team/tiers.md for these notes with a link in README.md

Copy link
Collaborator Author

@wks wks Dec 9, 2025

Choose a reason for hiding this comment

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

I removed all notes except the one for x86_64-apple-darwin. It tells the user that x86_64-apple-darwin may be replaced in the future.


1. Rust recently [demoted][x86appledem] x86_64-apple-darwin to Tier 2. We will replace it with aarch64-apple-darwin in the future.

[rustps]: https://doc.rust-lang.org/nightly/rustc/platform-support.html
[x86appledem]: https://github.com/mmtk/mmtk-core/issues/1365
[mmtk-art]: https://github.com/k-sareen/mmtk-art

## Contributing to MMTk

Thank you for your interest in contributing to MMTk. We appreciate all the contributors. Generally you can contribute to MMTk by either
Expand Down