[Open Discussion]: Discussing Crystal’s GC API for alternative memory managers

Community
1

Crystal already has a useful GC-facing runtime surface. Generated allocations are routed through GC.malloc, GC.malloc_atomic, and GC.realloc, and the standard implementations provide collection controls, explicit freeing, statistics, finalization-related hooks, and internal runtime support for stack handling and world stopping.

Compiling with -Dgc_none replaces Boehm with Crystal’s non-collecting fallback implementation, so it also makes it possible to experiment with a replacement implementation without linking Boehm.

However, the current surface is primarily shaped around conservative collection and the existing Boehm integration. It does not define a general contract through which another memory manager can receive compiler-known information such as:

  • reference layouts within allocations;
  • precise root locations;
  • managed-reference writes and aggregate copies;
  • safepoints and thread or fiber state;
  • pointer exposure and mutation through FFI;
  • object movement, pinning, or stable handles;
  • ownership and lifetime information for reference counting or regions.

The compiler and runtime already know much of this information while compiling and running a program, but it is not currently exposed through a collector-independent interface.

This matters if Crystal ever wants to support memory-management approaches beyond conservative tracing without requiring each implementation to maintain a compiler fork. That could include precise non-moving collectors, concurrent or generational collectors, compacting collectors, reference-counting hybrids, or region-based memory management.

I am not proposing a replacement for Boehm or a specific GC algorithm here. I would like to understand whether there is interest in discussing a general compiler/runtime contract for alternative memory managers.

In particular, I would appreciate feedback on:

  1. Are there previous discussions, issues, experiments, or rejected proposals related to this area?
  2. Is supporting alternative memory managers beyond conservative collectors a goal worth pursuing for Crystal?
  3. What constraints should shape the discussion from the start, especially around FFI, fibers, native threads, performance, and compiler maintenance?
  4. If this is worth pursuing, would a general interface be preferable to collector-specific compiler changes?

If there is interest, I can write an RFC using Crystal’s RFC template. It would begin with the current API, its compatibility requirements, and the missing compiler/runtime information before proposing any specific design.

3 Likes