Workspace heap retention versus OS release in Dyalog APL memory management

Short answer

No — in normal operation Dyalog APL does not return freed workspace heap memory to the operating system during a live session. When you erase an array, the space goes back onto the interpreter's internal free list, which is why ⎕WA recovers. The OS-level process size (RSS on Linux/macOS, working set on Windows) generally stays at its high-water mark until the session ends. There is no documented user-facing command or configuration option that forces a mid-session release of committed heap pages.

Confirmed facts vs. likely explanation

Confirmed: ⎕WA measures available space inside the interpreter's workspace heap, not OS memory. Erasing arrays is an internal free-list operation, so ⎕WA recovering while Task Manager or VmRSS stays elevated is expected behavior, not a contradiction and not by itself evidence of a leak.

Likely explanation: like most long-lived interpreters, Dyalog retains freed blocks in its allocator for reuse. Once the heap has grown to accommodate a peak workload, the process footprint typically stays there for the life of the session. How much the underlying C runtime could return also differs by platform — glibc on Linux may hand back large mmap-backed allocations but rarely shrinks the main arena, and the Windows heap has its own thresholds — so observed behavior can vary between builds and OSes.

MAXWS

MAXWS only caps the maximum workspace size. It limits how large the heap can grow; it does not trigger release of memory already allocated. Setting a smaller MAXWS will lower the peak footprint but will not make a running session shrink.

What to do in this case

1. Verify retention rather than assume a leak: in a loop, create and erase a large array, recording ⎕WA and OS process size each cycle (grep VmRSS /proc/<pid>/status on Linux, Task Manager on Windows). Retention shows RSS rising to a plateau and staying there; a real leak shows unbounded growth across identical cycles.
2. Repeat on the exact Dyalog version and platform you care about — allocator behavior is version- and build-sensitive, so results from one environment do not generalize.
3. If you genuinely need memory returned to the OS mid-workflow, save the workspace and restart the session, or push the memory-hungry work into a separate process you can terminate. That is the reliable mechanism; there is no in-session equivalent.

If you need a definitive, version-specific statement of the heap-release policy, raise the scenario with Dyalog support — it is an implementation detail not fully specified in public documentation.