Open
Conversation
sepcnt
force-pushed
the
feat-windows-support
branch
from
8226c63 to
b11ef21
Compare
* Implement `debug_print_object_info` for `ImmortalSpace` * Print `is_live` in `debug_print_object_global_info`
When running tests using OpenJDK, including binding tests and performance tests, we use both the `jdk-11` branch and the `jdk-21` branch of the repo https://github.com/mmtk/mmtk-openjdk Specifically, for binding tests, including both minimal tests and extended tests, we split OpenJDK 11 and OpenJDK 21 so that they are treated as two different bindings, and the CI will run tests for OpenJDK 11 and OpenJDK 21 in parallel. For performance tests, we simply use the `jdk-11` branch instead of the `master` branch. Since it points to the same branch as the current `master`, its behavior should not change.
Following the discussion in mmtk#1426 (comment), this PR prints more information in get-merged-pr to help figure out the problem.
This should fix mmtk#1426. I didn't test it, but the retry pattern is the same as in https://github.com/mmtk/mmtk-core/blob/76ef95a3da8b1f2f1420bfb71122ac37c77761b5/.github/workflows/auto-merge-inner.yml#L98-L103
We add a section in README.md and mention the level of support we provide for each platform (target triple) in a similar way the Rust project defines "tiers". Closes: mmtk#1430
Clippy warned "this assertion has a constant value" in a `debug_assert`. We replaced the `cfg!` expression with the `#[cfg]` attribute. Clippy treated a tuple constructor as double parenthesis by mistake. We extracted the tuple constructor into an explicit let-binding.
Tracing is exceedingly slow on biojava if we don't test-and-test-and-set. My guess is that we get cache line ping-pong when many workers try to mark the same popular objects; but every policy I checked has some sort of test-and-test-and-set pattern, and this seems like a common sense thing to do. [Plotty](http://squirrel.anu.edu.au/plotty/hayleyp/plots/p/GkUHfS) for a detailed before-and-after, although both configurations have some other changes to Compressor which I will upstream later. But this change still speeds up upstream - here is before: ``` ============================ MMTk Statistics Totals ============================ GC time.other time.stw total-work.time.min total-work.time.total total-work.time.max total-work.count 14 8575.41 14920.23 inf 0.000 -inf 0 Total time: 23495.63 ms ------------------------------ End MMTk Statistics ----------------------------- ``` And after: ``` ============================ MMTk Statistics Totals ============================ GC time.other time.stw total-work.time.total total-work.time.max total-work.time.min total-work.count 14 8826.60 9548.96 0.000 -inf inf 0 Total time: 18375.56 ms ------------------------------ End MMTk Statistics ----------------------------- ```
This PR updates the pinned Rust version to 1.92.0 and raises the MSRV to 1.84.0.It also cleans up several legacy workarounds and hacks that are no longer necessary with newer Rust versions.
We start using the MSRV-aware resolver (`resolver = "3"`).
We bumped dependency versions.
- We removed locked dependency versions that work around broken
transitive dependencies due to MSRV limitation.
- We still limit some of our dependency versions (`sysinfo` and
`criterion`) below the latest version because their latest versions
require higher MSRV and newer Rust editions.
- Note that the MSRV-aware resolver can find a compatible version only
within the allowed version range. For example, if we specify `0.7.2`, it
will be equivalent to `>=0.7.2,<0.8.0`. So if `0.7.4` is compatible but
`0.7.5` is not, it will resolve to `0.7.4`. But if `0.7.2` is
incompatible, the resolver will refuse to go below `0.7.2`, and the
resolution will fail. Both `sysinfo` and `criterion` broke MSRV
compatibility when bumping a minor version (since the major versions are
0, minor version signifies incompatibility), so the MSRV-aware resolver
is not helping for those two specific dependencies.
Removed a workaround in `ByteMapStateStorage::new` where we could use
`const {}` to initialize a vector without copying.
…Jan) (mmtk#1444) We observed a performance slowdown in CI results recently. The slowdown first appears in the 6th Jan CI run (before the Rust version upgrade which was on 12th Jan): the canary showed a ~3% regression on luindex, and openjdk-stickyimmix showed a similar slowdown. (Other benchmarks also show regressions; luindex is used here as the performance difference for luindex is most obvious) I also tested 3 builds ([`20251215`](mmtk@2ad6d36), [`20260106`](mmtk@473fd58), and [`20260112`](mmtk@e30d0a0)) with luindex (on a Zen 3 machine, rather than CI runenr's Zen 2), there was no measurable perf difference between those 3 builds. [link](https://squirrel.anu.edu.au/plotty/yilin/mmtk/#0|bear-2026-01-15-Thu-042440&benchmark^build^invocation^iteration&bmtime&|10&iteration^1^1|20&1^invocation|30&1&benchmark&build;jdk-mmtk-251215|41&Histogram%20(with%20CI)^build^benchmark&) <img width="2179" height="940" alt="ScreenShot_2026-01-15_181157_830" src="https://github.com/user-attachments/assets/3320418e-9033-47c0-8a70-b2e6f2dbfccd" /> @no-defun-allowed confirmed that there was a big update of all the packages for CI runners on 5th Jan. We started to see the difference on the commit in 6th Jan. So the performance difference is unrelated with MMTk moving to Rust 1.92 (which happened on 12th Jan). This PR updates `ci-perf-kit` to 0.8.6 which will plot 5th Jan as a new epoch.
This PR addresses mmtk#1420. This PR is based on top of mmtk#1418, and includes all the changes for Windows (for testing purpose). It is likely that Windows support will be removed from this PR, and will be merged separately. This PR does not try to refactor our malloc interface -- I am not sure if malloc should be included in the OS interface or not. This PR consolidates the current multiple mmap functions (such as dzmmap, mmap_fixed, mmap_noreplace, mmap_noreserve, etc), and use `MmapStrategy` to specify the expected mmap behavior. --------- Co-authored-by: sepcnt <30561671+sepcnt@users.noreply.github.com>
This reverts commit 4ab4f52.
This reverts commit 474d60a.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request adds initial Windows support to the project, focusing on enabling CI, memory management, thread affinity, and malloc functionality for Windows targets. The changes include updates to CI scripts and workflows to handle Windows-specific cases, platform-specific Rust code for memory and thread management, and a new implementation for malloc using Windows APIs.
Windows platform support
Cargo.tomland implemented platform-specific code for thread affinity and CPU detection insrc/scheduler/affinity.rs, using Windows APIs for processor count and thread affinity. [1] [2] [3] [4]src/util/malloc/library.rs, usingHeapAlloc,HeapFree, and related APIs; updated allocation logic insrc/util/malloc/malloc_ms_util.rsto support Windows. [1] [2] [3] [4] [5] [6]CI and workflow updates
.github/scripts/ci-common.shand.github/workflows/minimal-tests-core.ymlto add Windows jobs, set up bash shell defaults, and skip incompatible setup steps for Windows runners; also excludedmalloc_jemallocon Windows in feature initialization. [1] [2] [3] [4] [5] [6]Memory management abstraction
src/util/memory.rsto abstract memory protection, mapping, and error handling for Windows, including platform-specific flag translation and error codes, and using Windows APIs for memory operations. [1] [2] [3] [4] [5] [6] [7] [8]General codebase cleanup
libc::mprotectfromsrc/policy/copyspace.rs, replacing it with platform-abstracted memory protection functions. [1] [2] [3]These changes lay the foundation for building, testing, and running the project on Windows, with further improvements expected for full platform parity.