[go: nahoru, domu]

跳转到内容

逃逸分析:修订间差异

维基百科,自由的百科全书
删除的内容 添加的内容
Golaxy留言 | 贡献
新条目 逃逸分析
 
Golaxy留言 | 贡献
内容扩充 ==优化==编译器可以使用逃逸分析的结果作为优化的基础:将堆分配转化为栈分配。如果一个对象在子程序中被分配,要使指向该对象的指针永远不会逃逸,对象可能是栈分配的候选,
第1行: 第1行:
在编译程序优化理论中,逃逸分析是一种确定指针动态范围的方法——分析在程序的哪些地方可以访问到指针。它涉及到[[指针分析]][[形状分析]]
在编译程序优化理论中,逃逸分析是一种确定指针动态范围的方法——分析在程序的哪些地方可以访问到指针。它涉及到指针分析和形状分析。


当一个变量(或对象)在子程序中被分配时,一个指向变量的指针可能逃逸到其它执行线程中,或者去调用子程序。如果使用[[尾递归优化]](通常在[[函数编程语言]]中是需要的),对象也可能逃逸到被调用的子程序中。如果一种语言支持第一类型的[[延续性]]在Scheme和Standard ML of New Jersey中同样如此),部分[[调用栈]]也可能发生逃逸。
当一个变量(或对象)在子程序中被分配时,一个指向变量的指针可能逃逸到其它执行线程中,或者去调用子程序。如果使用[[尾递归优化]](通常在[[函数编程语言]]中是需要的),对象也可能逃逸到被调用的子程序中。如果一种语言支持第一类型的[[延续性]]在Scheme和Standard ML of New Jersey中同样如此),部分[[调用栈]]也可能发生逃逸。
第6行: 第6行:


逃逸分析需要确定指针所有可以存储的地方,保证指针的生命周期只在当前进程或线程中。
逃逸分析需要确定指针所有可以存储的地方,保证指针的生命周期只在当前进程或线程中。

==优化==
编译器可以使用逃逸分析的结果作为优化的基础:<ref name=":0">T. Kotzmann and H. Mössenböck, “Escape analysis in the context of dynamic compilation and deoptimization,” in Proceedings of the 1st ACM/USENIX international conference on Virtual execution environments, New York, NY, USA, 2005, pp. 111–120.</ref>

将堆分配转化为栈分配。如果一个对象在子程序中被分配,要使指向该对象的指针永远不会逃逸,对象可能是栈分配的候选,而不是堆分配。

同步省略。如果一个对象被发现只能从一个线程被访问到,那么对于这个对象的操作可以不考虑同步。

分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到,那么对象的部分(或全部)可以不存储在内存,而是存储在CPU寄存器中。

2015年7月3日 (五) 08:27的版本

在编译程序优化理论中,逃逸分析是一种确定指针动态范围的方法——分析在程序的哪些地方可以访问到指针。它涉及到指针分析和形状分析。

当一个变量(或对象)在子程序中被分配时,一个指向变量的指针可能逃逸到其它执行线程中,或者去调用子程序。如果使用尾递归优化(通常在函数编程语言中是需要的),对象也可能逃逸到被调用的子程序中。如果一种语言支持第一类型的延续性在Scheme和Standard ML of New Jersey中同样如此),部分调用栈也可能发生逃逸。

如果一个子程序分配一个对象并返回一个该对象的指针,该对象可能在程序中的任何一个地方被访问到——这样指针就成功“逃逸”了。如果指针存储在全局变量或者其它数据结构中,它们也可能发生逃逸,这种情况是当前程序中的指针逃逸。

逃逸分析需要确定指针所有可以存储的地方,保证指针的生命周期只在当前进程或线程中。

优化

编译器可以使用逃逸分析的结果作为优化的基础:[1]

将堆分配转化为栈分配。如果一个对象在子程序中被分配,要使指向该对象的指针永远不会逃逸,对象可能是栈分配的候选,而不是堆分配。

同步省略。如果一个对象被发现只能从一个线程被访问到,那么对于这个对象的操作可以不考虑同步。

分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到,那么对象的部分(或全部)可以不存储在内存,而是存储在CPU寄存器中。

  1. ^ T. Kotzmann and H. Mössenböck, “Escape analysis in the context of dynamic compilation and deoptimization,” in Proceedings of the 1st ACM/USENIX international conference on Virtual execution environments, New York, NY, USA, 2005, pp. 111–120.