V8 v7.4 现在支持无需在 runtime 阶段分配可执行内存就能执行 JavaScript 代码。
在其默认配置中，V8 很大程度上依赖于在 runtime 阶段分配和修改可执行内存的能力。例如，作为一个包含优化过程的编译器，TurboFan 可即时(just-in-time)为热加载 JavaScript(JS) 函数创建原生代码，并且大多数 JS 正则表达式由 irregexp 引擎编译为原生代码。而在 runtime 阶段支持创建可执行内存正是 V8 快速运行的原因之一。
但在某些场景中，我们可能需要刚好需要在不分配可执行内存的情况下运行 V8：
- 某些平台（例如 iOS、智能电视、游戏控制台）禁止对非特权应用程序的可执行内存进行写访问，因此到目前为止，在这些平台上一直无法使用 V8
- 禁止对可执行内存进行写操作可减少应用程序的攻击面
为此，V8 引入了名为 "JIT-less" 的新模式，旨在解决上面这些问题。当 V8 启动时带上 --jitless 参数，它就可以在没有使用任何 runtime 的情况下（无需分配可执行内存）来运行。
到这里，可能有人会问，这个 "JIT-less" 的工作原理到底是什么？对此，官方给出了解释。本质上，V8 只是基于现有的技术切换到了仅使用解释器(interpreter-only)模式：所有 JS 代码都通过 Ignition 解释器运行，同时对正则表达式模式匹配进行解释。虽然目前暂不支持 WebAssembly，不过可以对其进行解释。
而对于 V8 的内置程序，仍会将其编译为原生代码。但开发团队表示最近正努力将这些内置程序嵌入到 V8 二进制文件中，所以它们以后不再是 JS 堆栈。
最后，这些变更使得开发者所创建的 V8 不需要在任何内存区域申请可执行权限。
测试结果
正如上文所提到的，由于在 JIT-less 模式下禁用了优化编译器，因此会降低性能。
为此，开发团队研究了各种基准测试，以更好了解 V8 的性能是如何变化的。本次测试的比较对象包括：Speedometer 2.0、Web Tooling Benchmark 以及 YouTube TV Browsing
Speedometer 2.0 旨在代表典型的 Web 应用程序；Web Tooling Benchmark 包含了一系列常见的 JS 开发者工具；此外还提供了一个模拟在 Youtube 直播间浏览的基准测试。所有测试均在 x64 Linux 桌面系统上本地进行，运行次数超过5次。
△分数越高越好
可以看到，在 JIT-less 模式下，Speedometer 2.0 的性能大概下降了 40%。其中禁用的优化编译器占了大约一半的原因，另一半原因则是由正则表达式解释器引起的，该解释器最初用作调试辅助工具。
由于 Web Tooling Benchmark 会在 TurboFan 中花费更多时间，即它会重度依赖 TurboFan，因此在启用 JIT-less 模式后，测试结果显示下降了大约 80%。
对于最后的测试对象，可以看到性能变化不大。其测试过程包括视频播放和菜单导航，所以即使在 JIT-less 模式下，嵌入器也可以保持合理的性能。
最后，开发团队鼓励在受限制的平台或具有特殊安全要求的场景中尝试一下 V8 的新 JIT-less 模式，现在可在 V8 v7.4 版本中使用。
引用来自“kernel64”的评论
为啥没转用golang写引用来自“kernel64”的评论
为啥没转用golang写