Post-release dependency version bump for v0.21.0

[wks]

Bump the version of dependencies to their latest version.

The "atomic" crate, since version 0.6.0, requires the T in Atomic<T> to implement bytemuck::NoUnint. It is a marker trait for types that satisfies some requirements. One requirement is that T must not have any padding bytes (in the middle or at the end). The derive macro #[derive(NoUninit)] can be used on custom types to automatically check if the type satisfies its requirements. Two notable types are:

1. enum MMapStrategy. It is missing a representation annotation which NoUninit requires. This PR adds #[repr(u8)] to fix this.
2. WORKER_ORDINAL: Atomic<Option<ThreadId>>. The Option type does have padding bytes, making it un-eligible for Atomic<T>. This PR changes it to Atomic<ThreadId>, with ThreadId::max representing the uninitialized value.

[wks]

binding-refs
OPENJDK_BINDING_REPO=wks/mmtk-openjdk
OPENJDK_BINDING_REF=release/post-release-bump-v0.21.0

[udesou]

LGTM.

[k-sareen]

@wks The performance regression CI seems to be broken. Something about git dependency version.

[qinsoon]

@wks The performance regression CI seems to be broken. Something about git dependency version.

Maybe try manually merge mmtk/mmtk-openjdk#259 first. Then rerun the failed CI jobs.

The OpenJDK PR was not automatically merged due to an error here: https://github.com/mmtk/mmtk-core/actions/runs/7082168787/job/19272539610. The PR uses branch for the mmtk dep, and our script does not handle this case.

mmtk-core/.github/scripts/replace-mmtk-dep.py

Lines 68 to 69 in a058b8c

	# We assume the file already includes `git` and `rev`. We just update them. This will preserve the
	# original formatting and comments.

[wks]

Interestingly the mmtk-core PR is merged, but the mmtk-openjdk PR is not. I'll update and manually merge the mmtk-openjdk PR.

[qinsoon]

Interestingly the mmtk-core PR is merged, but the mmtk-openjdk PR is not. I'll update and manually merge the mmtk-openjdk PR.

The reason is what I wrote above. However, even if the mmtk-openjdk PR is merged as expected, we will still see failed jobs for mmtk-core perf CI, as those jobs are executed before the binding PRs are merged. I don't know if what would be a good way to deal with it (maybe we should wait until the binding PRs are merged and then execute the perf CI?)

[wks]

The reason is what I wrote above. However, even if the mmtk-openjdk PR is merged as expected, we will still see failed jobs for mmtk-core perf CI, as those jobs are executed before the binding PRs are merged. I don't know if what would be a good way to deal with it (maybe we should wait until the binding PRs are merged and then execute the perf CI?)

Yes. I think we should re-run the perf CI once the binding PR is merged. PRs may fail to merge for one reason or another, and there should be a way to manually trigger those things.

[wks]

I restarted the performance regression CI after merging the mmtk-openjdk PR https://github.com/mmtk/mmtk-core/actions/runs/7083003792