毕业设计

1. 毕业设计 龚军

2. 内容 • 新的框架 • Code Cache的管理

4. 通信机制 • 执行进程 • 将待翻译的函数的地址传递给优化进程 • 执行进程需要传递给优化进程的信息有： • 待翻译的函数地址 • 优化进程 • 获取待翻译的函数的地址 • 放置本地码 • 优化进程需要传递给执行进程的信息有： • 生成的本地码，以及和本地码相关的信息（需要传递函数中设为entry的tb的值）

5. 进程间通信方式 • 传统的文件 • 管道、消息队列、信号量、共享存储 • 根据上述通信方式的特点 • 通过管道传递待翻译的函数的地址 • 通过共享存储区中存放 • 优化进程产生的本地码，以及相关的tb值 （分别用两个共享存储区存储）

6. 打patch • 链接执行进程和优化进程产生的本地码 • 由谁打patch • 如果把执行进程的code cache放在共享存储区里，则可以由优化进程打patch • 缺点是对这段code cache的赋值和访问可能开销很大。 • 否则需要由执行进程里的某个线程打patch • 可以在执行进程另启一个线程专门打 patch • 当执行进程里的线程返回BT控制器时，检查是否有TB需要打patch • 缺点是有可能执行线程里的本地码都链接起来了，不再返回BT控制器，或者返回BT控制器的时间比较迟

7. 打patch • 打patch会出现需要打两次patch的情况：优化进程产生的本地码链接到执行进程产生的本地码（A’链接到B，此时优化进程产生相应的本地码B’），后来又要链接到优化进程产生的本地码B’（即将A’链接到B’）

8. Code Cache的管理 • Code Cache的管理粒度 • 分块(Unit)管理 • 有一种策略：分Unit的FIFO替换策略，它利用了FIFO策略较好 的程序局部性和较小的开销，并通过对一个Unit的本地码统一处理的方式进一步减小了Code Cache管理带来的开销，并减少了碎片的数量。

9. Code Cache的管理粒度 • 以函数为单位对Code cache进行管理 • 为什么要以函数为单位进行管理 • 方便以函数为单位对code cache进行回收：优化进程 生成某个函数的本地码以后，就可以即时回收该函数在在执行线程对应的本地码所占用的code cache空间，而不用等到code cache 不够时再回收 • 具体细节 • 函数所占的code cache空间以free list的方式进行记录，记录每个函数所占用的code cache空间，大小是不固定的。

10. Code Cache分配机制 • 有可能有很多分开的code cache空间 • 按照最适分配进行分配

11. 回收机制 • 当优化进程中产生某个函数的本地码时，进行即时回收 • 如果该函数被执行进程翻译过（函数整体或者部分被翻译了） ，则可以对这部分内存进行回收 • 回收分为两步 • 打patch，阻止任何线程再进入执行进程产生的本地码 • preconnect • shadow stack • loop entry（启发式地设置entry） • 间接跳转 • 回收 • 向执行进程里的所有线程发信号，检查其是否在要回收的本地码里 • 合并相邻的未使用的code cache

12. 如果Code Cache不够用了怎么办 • 采用FIFO的方式进行回收 • 断链 • 回收 • 根据函数热度进行回收 • 最理想的情况是：所有的热函数都放在一起（根据lzs所做的实验，把热度高的函数放在一起，对CPU2006的平均性能能提高2%~3% • 难点： • 如果要精确地统计函数的热度，会有一定的开销（时间+空间）

13. 需要注意的问题 • 处理非对齐 • 需要把非对齐的那块地址也记录到函数所占的code cache空间里

14. Thank You!