Page 59 - 《软件学报》2021年第12期

张杨 等:基于下推自动机的细粒度锁自动重构方法 3723

使用的百分比随着线程数变化的情况.从图 9(a)可以看出:当吞吐量达到峰值之后,使用同步锁的吞吐量要比使
用细粒度读写锁的吞吐量稍微高一些.这也说明并不是所有情况下,使用细粒度读写锁性能都比使用同步锁要
好.图 9(b)给出了在不同线程执行情况下使用的堆内存占总内存的百分比,在线程数为 8 时,程序重构前的堆内
存使用占比高于程序重构后;而在线程数为 12 时,程序重构后的堆内存使用占比高于程序重构前.这说明在不
同锁模式和不同线程数下堆内存的使用情况各有不同,而我们设计的重构工具为开发人员提供一种快速的细
粒度锁和粗粒度锁重构的方式,开发人员可以通过测试来找到程序堆内存使用最合适的情况.
240000 100
同步锁
220000 同步锁 细粒度读写锁
细粒度读写锁
80
200000 (%)
事务吞吐量(Bops) 160000 堆内存使用比 60
180000
40
140000
120000
20
100000
80000 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
线程数 线程数
(a) 事务吞吐量 (b) 堆内存使用比
Fig.9 Performance comparison of the SPECjbb2005 benchmark before and after refactoring
图 9 SPECjbb2005 重构前后的性能比较
5.3.6 工具对比
[5]
我们将 FLock 和已有的重构工具 Relocker 进行了对比.Relocker 是 Schafer 等人设计实现的一个自动重构
工具,可以把同步锁重构为可重入锁或读写锁.该工具是一种粗粒度锁的推断模式,不能实现细粒度的加锁模
式.由于 Relocker 工具开发较早,不支持高版本的 JDK,因此在该实验中使用的 JDK 版本为 1.6.测试程序选择了
HSQLDB 和 Cassandra,版本分别为 1.8.0.10 和 0.4.0(比表 1 的版本低),这两个程序中包含的同步锁的数量也较
之前实验选取的版本有所不同:HSQLDB 总共包含 266 个同步锁,Cassandra 总共包含 57 个同步锁.我们也尝试
使用 Relocker 对其他测试程序进行重构,但由于 Relocker 开发较早,均不支持对这些版本进行重构.
表 3 给出了 Relocker 和 FLock 重构结果的对比,可以看出:Relocker 只使用读锁或写锁进行同步保护,而且
还存在不能重构的问题;FLock 不仅可以推断读锁和写锁,而且可以实现更为细粒度的锁重构.在读锁的推断上,
FLock 比 Relocker 推断出了更多的读锁,经人工验证,使用 FLock 进行重构后的读锁使用正确.Relocker 的推断
结果不准确的原因可能与分析深度有关,这里的分析深度使用的是 Relocker 的默认值.在重构时间上,Relocker
重构 HSQLDB 耗时 7s,FLock 耗时 6s;Cassandra 程序规模较大,Relocker 重构耗时 50s,FLock 重构耗时 42s.总体
来看,FLock 在重构效率上有所提升.
Table 3 Comparison of Relocker and FLock
表 3 Relocker 和 FLock 重构对比
Relocker FLock
名称
读锁 写锁 不能重构 时间(s) 锁降级 锁分解 读锁 写锁 时间(s)
HSQLDB 1.8.0.10 31 212 23 7 8 23 45 190 6
Cassandra 0.4.0 4 50 3 50 3 1 6 47 42
[7]
我们还将 FLock 与重构工具 CLOCK 进行了对比,CLOCK 是一个面向邮戳锁的自动重构工具.这里选取
了本文实验中监视器对象相对较多的 7 个测试程序进行重构对比,实验结果见表 4.由于邮戳锁是不可重入锁,
所以 CLOCK 对部分临界区不能执行重构,其中,HSQLDB 和 SPECjbb 2005 包含较多不能重构的锁,分别为 61
和 75 个;由于 CLOCK 在锁推断上和 FLock 不同,所以在锁降级重构数量上也有所差异.两个工具在重构效率
上,CLOCK 在重构 HSQLDB,Cassandra 和 Fop 时比 FLock 慢 1s~2s,其他程序在重构时间上基本一致.