While I could understand needing to unceremoniously abort an entire process if the entire process literally ran out of memory that the OS had allocated to it, it seems that it should certainly be possible, at least in theory, for an embedder to track heap allocations by an isolate, and to invoke a TerminateExecution on the isolate long before the process allocations exceed actual OS limitations. If an embedder does *NOT* attempt to terminate an isolate that it could so otherwise detect was behaving so inappropriately, then of course a crash might still be an appropriate response. The embedder could detect via a TryCatch that the isolate cannot continue, and so handle what could be detected as an out of memory condition in that way.
I don't know of any mechanism in the embedder's api for tracking absolutely all of an isolate's heap allocations for its data, however, so there is no way that I can see for an embedder to do this, however. I also can't see how this would have measurable performance impact above and beyond what already clearly exists for handling the case where TerminateExecution is invoked on an isolate from another thread, which appears to be working just fine.