2024-1-11讨论班

Posted on Edited on In

Contextual Dispatch for Function Specialization

OOPSLA’20

JIT对函数的优化策略是根据上下文来决定的，以R为例

  • 需要在函数调用之前编译器插入类型检查代码
  • 运行时如果发现参数类型变了就trigger recompiling
  • 根据最近的调用删除一些参数的类型检查(如果用不到)以加速

缺点：

  • 综合多次调用可能不是最优的优化
  • deoptimize/recompile的过程比较花时间

方法：

  • 空间换时间，记录context->code version表，call函数需要查表
  • Context记录什么信息……
  • 对Context的可能值建立偏序(因为同一个context可能有多个次优化版本)关系，每次从表里找到>=当前ctx的最小的ctx’。若ctx’大于ctx，取ctx’的子节点，取其优化规则的并集重新编译然后插进来，若满了就随机逐出一个

Comment：

  • 没说内存占用
  • 我感觉这个工作有点捞

WaVe: a verifiably secure WebAssembly sandboxing runtime

S&P’23

主要讨论wasm的安全性

内存隔离：每个程序都有一块独立的区域

  • 总内存12G，规范要求从4G地址开始，总可用空间不超过4G，前后至少8G是guard page(可能motivated by±int32)

WebAssembly System Interface(WASI)的挑战：

  • 缺乏完备的WASI规范
  • 需要保证资源隔离
    • 内存隔离
    • 文件系统隔离
    • 网络隔离(说constraint更适合一定)

例如对于一个删除文件夹的API

  • 需要验证path字符串的地址是否在合法内存内
  • 需要验证路径是否在根目录内
  • 调用POSIX中的对应函数

WaVe：一个可验证WASI安全的Wasm Runtime

静态扫描WASI(实验用的是他们自己实现的)函数中的Effect，包括

  • 内存操作/文件操作/网络操作(共7种)
  • 对每种Effect有检验规则，静态检查

Evaluation：

  • 通过Fuzz验证正确性
    • AFL
    • 通过QuickCheck验证pre-post-condition
    • 随机生成syscall差分测试
  • 和wasmtime比较运行时性能【非静态检查的性能，没啥意义的测试】

Contribution主要在于给出了一个WASI实现的标准/流程，可以仿照他们的工作做个验证器，然后给定验证条件来实现需要的API