smalltalk - 为什么某些 block 闭合优化是好的和有效的？

Question

在一个非常有趣的post从 2001 年开始，Allen Wirfs-Brock 解释了如何在不具体化(原生)堆栈的情况下实现块闭包。

从他公开的许多想法中，有一个我不太理解，我认为在这里问它是个好主意。他说:

任何在块的生命周期内永远不能被赋值的变量(例如，封闭方法和块的参数)不需要放置在环境中，如果在创建时将变量的副本放置在闭包中

有两件事我不确定我是否理解得足够好:

为什么使用只读变量的两个副本比将变量移动到环境中更快？是否因为封闭上下文访问堆栈中的(原始)变量会更快？

我们如何确保两个变量保持同步？

在问题1中，肯定有另一个原因。否则我看不到 yield (与实现优化的成本相比。)

对于问题 2，采用在方法中而不是在块中分配的非参数。为什么存储在堆栈中的 oop 在块的生命周期内会保持不变？

我想我知道 Q2 的答案:因为块的执行不能与方法的执行交织在一起，即当块存在时，封闭上下文不会运行。但是没有任何方法可以在块处于事件状态时临时修改堆栈吗？

Answer 1

感谢@aka.nice 的评论，我在 Clement Bera 的帖子中找到了这两个问题的答案，他的文章读起来既愉快又清晰。

对于Q1，我们首先说Allen 的评论意味着只读变量的副本可以放在块的堆栈中，就好像它是块的本地临时文件一样。只有当所有在块外部定义并在块内部使用的变量都从未写入块时，这样做的优势才会体现出来。在这些情况下，不需要创建环境数组并发出任何序言或结语来处理它。

访问堆栈变量的机器代码等同于访问环境变量所需的机器代码，因为第一个将使用 [ebp + offset] 寻址该位置。而第二个将使用 [edi + offest] , 一次 edi已设置为指向环境数组(Clement 表示法中的 tempVector)。因此，如果某些但并非所有环境变量是只读的，则没有任何好处。

第二个问题也在 Clement 的优秀博客中得到了解答。是的，还有另一种方法可以打破原始变量与其在块堆栈中的副本之间的同步:调试器(正如 aka.nice 会告诉我们的那样!)如果程序员在封闭上下文中修改变量，调试器将需要检测操作并更新副本。如果程序员修改了块堆栈中保存的副本，则相同。

我很高兴我决定在这里发布问题。我从 aka.nice 和 Clement Bera 那里得到的帮助，加上一些人通过电子邮件发给我的评论，对我的理解有很大帮助。

最后一句话。 Wirfs-Brock 声称避免方法上下文的具体化是强制性的。我倾向于同意。但是，如果具体化遵循轻量级模式，则​​可以更好地实现对这些数据结构的许多重要操作。更准确地说，在调试时，您可以使用指向 native 堆栈的“查看器”对这些上下文进行建模，并使用两个索引来分隔与正在分析的激活对应的部分。这既高效又干净，两种技术的结合带来了世界上最好的，因为你可以同时拥有速度和表现力。 Smalltalk 是惊人的。