Page 132 - 《软件学报》2021年第7期

2050 Journal of Software 软件学报 Vol.32, No.7, July 2021

Table 1 Information of subjects
表 1 对象信息
Programs Size (KLOC) Description URL
Transmission 81.835 BitTorrent 客户端 https://github.com/transmission/transmission
LunchBox 20.826 C++多线程库 https://github.com/Eyescale/Lunchbox
FineDB 15.310 Nosql 数据库 https://github.com/Amaury/FineDB
sofa-pbrpc 320.743 轻量级 RPC https://github.com/baidu/sofa-pbrpc
s3fs-fuse 16.234 基于 FUSE 的文件系统 https://github.com/s3fs-fuse/s3fs-fuse
axel 4.608 轻量级命令行下载器 https://github.com/axel-download-accelerator/axel
leveldb 25.438 一个 key-value 数据库 https://github.com/google/leveldb
zfs 491.393 一个文件系统 https://github.com/openzfs/zfs
lwan 17.145 一个网页浏览器 https://github.com/lpereira/lwan
zfs-fuse 213.402 Fuse 下的 ZFS 文件系统 https://github.com/gordan-bobic/zfs-fuse
rsyslog 124.333 一个日志处理系统 https://github.com/rsyslog/rsyslog
RedAlert 139.407 监控服务 https://github.com/alibaba/RedAlert
zcash 1 350.028 “Zerocash”协议的实现 https://github.com/zcash/zcash

5.2 GUARD的效率

表 2 中第 2 列和第 3 列展示了构建 TFG 及分析线程标签的性能信息.第 4 列和第 5 列展现了查询 MHP 的
性能表现.第 4 列是平均查找时间,第 5 列是查询次数.从表 2 中可以看出一半以上的程序都能在 1s 内完成分析,
所以 GUARD 是足够高效的.大多数测试程序所消耗的内存也很低.可以看到,所有程序都能在 3.6GB 的内存消
耗内完成 MHP 分析.在识别 MHP 关系方面,MHP 查询所消耗的总时长的几何平均为 0.331s.其中只有 5 个程序
查询 MHP 关系的时间超过 1s.通过表 2 可以得出结论:GUARD 是十分高效的.
Table 2 Analysis results of GUARD
表 2 GUARD 的分析结果
MHP build Info. MHP query Info. Race analysis Info. Detection Info.
Programs Ave. query Static Manual
Time (s) Memory (MB) #query Time (s) Time (s) Memory (MB)
time (s) analysis checking
Transmission <1 40 15.6 5 371 0.084 201 3 018 2 2
LunchBox <1 60 22.0 1 003 0.022 15 1 614 2 2
FineDB <1 5 33.2 600 0.020 14 873 1 1
sofa-pbrpc <1 107 11.5 19 211 0.221 536 11 408 2 2
s3fs-fuse <1 33 13.0 6 592 0.086 42 2 261 2 1
axel <1 3 13.3 901 0.012 192 1 002 6 6
leveldb <1 34 23.1 173 0.004 31 2 255 10 10
zfs 80 147 588.2 36 864 21.685 1 077 10 033 8 3
lwan 1 146 17.8 1 745 0.031 117 1 246 5 5
zfs-fuse 123 3 532 13 745.9 3 880 53.348 3 247 11 341 29 19
rsyslog 45 2 008 12.2 14 861 0.181 1 863 6 6
RedAlert <1 109 4.5 221 0.001 51 5 751 1 1
zcash <1 61 948 N/A 0 0 1 870 36 799 0 0

表 2 中第 7 行和第 8 行是程序的数据竞争检测结果.我们分析了每个程序的执行时间和内存需求.关于前
12 个程序,它们的大小从 4.6KLOC 到 491.4KLOC 不等,都在 1 小时内、11GB 内存条件下完成了分析.数据竞
争检测时长的几何平均为 83.7s,内存消耗的几何平均为 2 734.0MB.最后一个程序需要相对更多的资源进行分
析.可以看到,GUARD 能够在 1 870s 内消耗 36GB 内存完成对 1.3MLoC 规模程序的分析.
表 3 是不同工具所消耗的时间和内存的比较.T 代表总执行时间,Mem 是最大消耗内存.TO 意为超时
(TimeOut),Crash 代表出现了段错误,OOM 表示内存不足.在计算效率提升时,我们忽略所有失败的分析结果(即
TO、Crash 和 OOM),因为它们的分析时间是未知的.从表中可以看出,在分析小规模程序时,GUARD 并不是最
高效的.但是,GUARD 在所有测试程序上平均加速为 6.08 倍.代码规模在 10KLOC 以上的程序为平均分析速度
的提升提供了主要的贡献.具体而言,LOCKSMITH、LDruid、Relay、Goblint 和 GUARD 分析时间的算数平均
值为 55.50s、80s、3.67s、79.83s 和 25.00s,消耗内存的算数平均值为 767MB、322.8MB、49.7MB、194.3MB
和 563.8MB.由于只有 GUARD 能够分析所有程序,所以针对每个工具的平均分析提升只考虑 GUARD 和它都