Swizzling uses wrong memory map

[QDucasse]

Note: This is only the case for the RISC-V board that uses a different memory map than regular 64 bits platforms

Saving an image on X64 with the memory map layout for 64-bits:

#       define ConfWordSize 8
#       define CodeZoneInitialAddress   0x320000000   //  "12.5GB";
#       define NewSpaceInitialAddress   0x360000000   // "13.5GB";
#       define OldSpaceInitialAddress   0x10000000000 // "1024GB";
#       define PermSpaceInitialAddress  0x20000000000 // "2048GB";
#       define StackPagesInitialAddress 0x300000000   // "12GB";

And then loading it with a different memory map:

#       define ConfWordSize 4
#       define CodeZoneInitialAddress   0x10000000  // "(256 MB)"
#       define NewSpaceInitialAddress   0x20000000  // "(512 MB)";
#       define OldSpaceInitialAddress   0x40000000  // "(1024 MB)";
#       define PermSpaceInitialAddress  0x80000000  // "(2048 MB)";
#       define StackPagesInitialAddress 0x0F000000  // "(240 MB)";

Breaks the swizzleObj as it checks for a greater address than the PermSpaceInitialAddress. It is always true if the new memory map is smaller and then it never swizzles the pointers.

Potential idea for fix: The image should store the address of the permanent space start at save time (or the entire memory map) and the swizzle needs that as argument at load time.

[takano32]

Your diagnosis and proposed fix look right to me, and I'd like to connect this to the VA39 work that just landed, because I think #955 is the remaining, complementary half.

What the merged VA39 fix already does (the runtime side). #1079 (merged) lets the VM start when a space can't be mapped at its configured base: the platform allocator falls back to a reachable address, and VMMemoryMap>>calculateMaskToUse now recomputes the space-discrimination masks from the address actually obtained instead of the compile-time constant. #1107 generalizes that fallback to any user address-space size. So on a smaller memory map the VM boots and old-space objects are discriminated correctly at runtime.

What it deliberately did not touch (the image-format side — this issue). Two things still assume the compile-time map:

1. Perm space hard-errors instead of swizzling. In ComposedImageReader>>readPermanentSpaceFromImageFile:..., the saved base is read as permSpaceMetadata startAddress (oldBase), the space is allocated at newBase := permSpaceStart, and then:

   newBase ~= oldBase ifTrue: [
       self logError: 'Expecting Base %p Got %p' _: oldBase _: newBase.
       coInterpreter unableToReadImageError ].
   

   i.e. it refuses the image rather than swizzling perm-space oops from oldBase to newBase. Contrast old space, which is relocatable: SpurImageHeaderStruct carries oldBaseAddr, and the reader swizzles old-space pointers by the load-vs-save delta. Perm space just never got the same treatment — which is exactly the "never swizzles" you describe.

2. The discrimination predicate still compares against the constant. VMMemoryMap>>isPermanentObject: is ^ anOop >= self fixedPermSpaceStart, and SpurSegmentManager>>swizzleObj: short-circuits on it. So even once perm space is relocated, the predicate must compare against the effective (obtained) perm base, mirroring what calculateMaskToUse already did for the masks.

So a complete fix is the two halves of your idea:

• (a) Record the save-time bases in the image (per space, or the whole map) — perm space already stores its startAddress in the composed metadata, so the writer side is largely there; old space already stores oldBaseAddr. The gap is a uniform "every space carries its save-time base."
• (b) At load, swizzle each space's oops from saved-base to load-base, and derive the space predicates from the obtained bases rather than the constants (the runtime machinery from Minimal ARM64 VA39 support, enabling the VM to run on ARM Chromebooks #1079 is the natural place to feed them).

Design questions worth settling first (happy to draft these as a follow-up if useful):

• Image-format versioning + the backward-compat matrix: old-VM × new-image and new-VM × old-image, with a defined behavior for each cell.
• Whether to store the full map or per-space bases, and where (extend the composed metadata / SpurImageHeaderStruct).

Coordination: this overlaps with #1078 (just merged — relocating codeZone/newSpace/stackPages below the macOS dyld cache, i.e. the low-address-floor mirror of VA39's high-address-ceiling) and #1043 (WIP, mmap-loading PermSpace). A "map is data, not compile-time constants" design should probably cite all three.

I have a real aarch64 VA39 machine (the hardware #1079 was written for), so I can test the save-on-VA48 / load-on-VA39 round-trip end to end. Happy to prototype the perm-space swizzle + obtained-base predicates if that's a direction you'd welcome — no rush, and I don't want to step on #1043 if @tesonep is already taking the PermSpace side.