VM_LAYOUT: References to mut static

[wks]

In the Rust 2024 Edition it will be a compilation error to create & and &mut of static mut variables. See https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-reference.html

Although the 2024 edition not yet released, the current stable Rust (1.77.0) warns against this. See: https://doc.rust-lang.org/1.77.0/rustc/lints/listing/warn-by-default.html#static-mut-refs

This is causing some CI tests to fail. See https://github.com/mmtk/mmtk-core/actions/runs/8417778415/job/23046912436?pr=1067

Currently, only crate::util::heap::layout::vm_layout::VM_LAYOUT is affected.

(Note: There is another use case of static mut in mock_test_doc_avoid_resolving_allocator.rs, but it seems unnecessary.)

A simple workaround is possible. Change &VM_LAYOUT to unsafe { &*addr_of!(VM_LAYOUT) }, and the warning goes away.

But it reveals a problem. VM_LAYOUT is global. The function fn vm_layout() -> &'static VMLayout is used in 90+ different places in mmtk-core, and they all treat it as a global constant struct. But VM_LAYOUT is actually mutable (by set_custom_vm_layout). More precisely, it is immutable after initialization for each MMTK instance, as is explained in the doc comment:

    /// ...
    /// This function must be called before MMTk::new()
    pub(crate) fn set_custom_vm_layout(constants: VMLayout) {

The proper fix is moving the VMLayout structure to a field of MMTK, and make all functions that depend on it a method of MMTK

For example, fn memory_manager::starting_heap_address() -> Address and fn memory_manager::last_heap_address() -> Address should be methods of MMTK because each MMTK instance should have its own heap range.

As another example, VMLayout is frequently used when creating spaces and page resources. Spaces and page resources belong to each MMTK instance. Understandably, if VMLayout is a per-MMTK constant, it should be a parameter to the constructor of MMTK, and therefore it can be passed to the constructors of spaces and page resources. We discussed refactoring the creation of spaces and page resources in another issue: #932