Gleam FFI Atom Handling vs BEAM Non-GC Atom Table Boundary

Integration Boundary

Gleam's @external FFI mechanism maps Gleam functions to Erlang modules, with a dedicated Atom type representing BEAM atoms. The BEAM runtime maintains a global atom table that is not garbage collected in standard implementations, while Gleam's type system treats atoms as first-class values subject to normal scoping rules.

Unresolved Behavior

When Gleam code frequently constructs or receives distinct atoms via FFI—such as dynamically generated error tags, protocol messages, or map keys—each unique atom permanently occupies a slot in the VM-wide table. The Gleam compiler cannot statically bound the cardinality of atoms produced at runtime, and the BEAM provides no built-in backpressure or eviction policy for the atom table.

This creates a tension: Gleam encourages expressive atom usage for domain modeling, yet the underlying runtime imposes a hard, process-global limit (default 1,048,576 entries) that, once reached, crashes the entire VM.

Questions

1. What strategies exist to monitor atom-table pressure from within a Gleam application without resorting to Erlang-specific diagnostics?
2. Can the Gleam compiler or build tooling emit warnings when FFI signatures suggest unbounded atom generation?
3. Are there documented patterns for safely interning or reusing atoms across Gleam–Erlang boundaries to avoid table exhaustion?