[POC] gc: permanently mark pkg/sysimage objects to speed up GC

[topolarity]

Image objects are already never freed and are ~somewhat rarely mutated, making them candidates for "pretenuring".

Load image objects as permanently marked (GC_OLD_MARKED) so gc_try_setmark_tag returns 0 immediately and the mark phase never enters the image subgraph. Maintain any mutations as a dedicated image_remset which effectively roots any "new" referents that are referred to by the image subgraph.

This significantly speeds up (full) GC pause times when dominated by immutable objects in the sysimage / pkgimage heaps:

  GC full (not partial / quick) collection times:
  ┌───────────────────────────────┬─────────┬─────────┬─────────┐
  │           Benchmark           │ 1.12.5  │ Nightly │ This PR │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 1. Baseline (sysimage only)   │ 37.3 ms │ 40.3 ms │ 1.4 ms  │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 2. After loading packages     │ 39.4 ms │ 43.2 ms │ 3.4 ms  │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 3. Allocation pressure (1 MB) │ 40.0 ms │ 43.7 ms │ 3.5 ms  │ 
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 4. Growing live set           │ 40.8 ms │ 43.8 ms │ 4.0 ms  │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 5. After method definitions   │ 40.5 ms │ 43.0 ms │ 4.1 ms  │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 6. Heavy JIT (eval in loop)   │ 42.3 ms │ 47.1 ms │ 7.4 ms  │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 7. Mixed 5-cycle pattern      │ 84.4 ms │ 93.3 ms │ 10.9 ms │
  ├───────────────────────────────┼─────────┼─────────┼─────────┤
  │ 8. Large transient (10 MB)    │ 41.8 ms │ 46.7 ms │ 4.4 ms  │
  └───────────────────────────────┴─────────┴─────────┴─────────┘

Partial / "quick" GC pause times are essentially unchanged. Benchmark script

Co-authored-by: Claude Opus 4.6 noreply@anthropic.com 🤖
This commit is almost entirely written by Claude after laying out a plan together.

Draft because I think the sweep in staticdata.c is probably unnecessary. I'm hoping to remove that before this is ready for review. (edit: done) This can likely also be generalized slightly to a "permalloc / pretenure" operation that applies to objects not necessarily in images. I'm not sure whether it'd be possible "unfreeze" those objects once they are promoted to permalloc'd / pretenured though.

[vchuravy]

I don't quite follow why we need a different remset? The core of the remset idea is that we keep track of the dynamic frontier between generations, so I don't see anything preventing us from using the current remset for the eternal/permalloc generation.

Or is the issue that during mark we need to keep track off if they object is coming from an image?

So my idea would be that during a full GC you could look at the remset and scan all eternal objects. This would move us more cleany to a three generation GC, and of course the write-barrier would need to enque eternal objects that see writes of child objects in the young or old generation

[topolarity]

So my idea would be that during a full GC you could look at the remset and scan all eternal objects. This would move us more cleany to a three generation GC

You're saying to compact the existing remset instead of clearing it? Sounds potentially expensive, but we could do that.

IIUC multi-generation GC's usually do separate the remsets between generations, since it's unnecessary to scan through the remsets collected for younger generations. They just often distribute the remset across regions so that each region is only in one remset at a time. Or am I missing something?