MemoryConstrained

Evaluates expr under a memory cap of bytes — real only in the isolated evaluator.

✓ checked against that system · ! checked, with disagreements (hover a chip)Wolfram LanguageMemoryConstrained!↗

MemoryConstrained(expr, bytes[, failexpr])in-process, stays unevaluated; real only inside evaluateIsolated. Over the cap it returns failexpr, or Aborted without one.

Typed signatures

Type	Package	Applies
(any, real<0..>, any?) environment -> any	evaluation	always

Domain: Controlling evaluation

Details

• JavaScript cannot cap the memory a synchronous, in-process computation uses. In-process, MemoryConstrained therefore stays unevaluated rather than pretending to enforce a bound it cannot — silently ignoring the constraint would be worse than saying so plainly.
• The bound is real inside @enumeratio/evaluation/node's evaluateIsolated: the worker's own resourceLimits.maxOldGenerationSizeMb, a heap cap the runtime itself enforces.
• Aborted is Wolfram's $Aborted: our names never carry a $ prefix, and the Wolfram transpiler writes the $ at the boundary.
• Held: expr and failexpr are not evaluated in-process, since there is nothing here to run them under.

Examples

Basic #

In-process, the call simply does not reduce — see evaluateIsolated for the real cap

live ↗

In$\mathrm{MemoryConstrained}(1+2, 1\,000\,000)$Out$\mathrm{MemoryConstrained}(3, 1\,000\,000)$

Scope #

A failexpr does not change that: in-process there is no cap to exceed

live ↗

In$\mathrm{MemoryConstrained}(1+2, 1\,000\,000, -1)$Out$\mathrm{MemoryConstrained}(3, 1\,000\,000, -1)$

About

Examples	2
Checked against	Wolfram Language 2 differ
Crosswalk	Wolfram Language