[chrismccord]

A DurableServer process never hibernates, so an idle server keeps its heap at its high-water mark. In one production deployment, an idle server held about 1.06 MB, of which 54 KB survived a GC (live state: 38 KB). With thousands of mostly idle servers per node, that's gigabytes held for nothing.

Change

DurableServer.Supervisor accepts :hibernate_after on the mount, next to the other per-module settings:

{DurableServer.Supervisor,
 name: MyApp.DurableSup,
 max_children: %{MyApp.SessionServer => 5_000},
 hibernate_after: %{MyApp.SessionServer => 15_000, default: 60_000}}

• An integer applies to every module under that supervisor.
• A map of Module => ms applies to the listed modules. A :default key covers modules not listed; without it, unlisted modules don't hibernate.
• nil (default): no change from today.

The supervisor starts every child through one child spec with its config, including start_child, restart claims, rehoming and preloaded boot. So DurableServer.start_link/1 looks up its module and passes hibernate_after: to GenServer.start_link/3. The lookup is by module name, so it works whether or not the module is loaded yet. Invalid values are rejected when the supervisor starts.

Tests

• A per-module map hibernates only the listed modules.
• :default covers unlisted modules.
• An integer applies to every module.
• With no setting, servers never hibernate.
• Invalid values fail at start.

The "does hibernate" tests fail without the start_link change. On OTP 28, a hibernated gen_server reports gen_server:loop_hibernate/4; the tests accept that and the older erlang:hibernate/3.