Good question! Nothing in SafeScript itself prevents it. Instrumenting the code to prevent this would be too costly. A script can do

  var a = [];
  for (var i = 0; i < 10000000; i++)
   { a.push({x: i}); }

In PHP the situation is excellent. That’s language has support for checking how much memory was used, so our injected checks already works there:

  if ($d > 0 && ($o === null || ($o % 1000) === 0)) {
    if (microtime(true) >= $d) {
        throw new \RuntimeException('SafeScript: timeout exceeded');
    }
    $ml = $GLOBALS['__safescript_memory_limit'] ?? 0;
    if ($ml > 0 && memory_get_usage() > $ml) {
        throw new \RuntimeException('SafeScript: memory limit exceeded (' . $ml . ' bytes)');
    }
  }

For native embedded applications, where SafeScript is positioned to replace Lua, the situation is quite good. QuickJS already has JS_SetMemoryLimit() - a hard byte ceiling, which throws when hit. In fact the https://github.com/SafeScript/safescript-quickjs repo already uses this.

You can think of this as the “belt-and-suspenders” approach. Perhaps a future version of SafeScript would instrument the actual imperative code to catch these, same as it catches a script that tries to peg the CPU. But so far, I haven’t found a good way, without totally overriding most Javascript primitives, objects and operations. Any suggestions?

Does the system do its own allocations with a memory block or does it basically depend on the host to malloc?