1.对比测试
1.1.测试环境
笔记本（3.1 GHz Intel Core i5, 4Gb RAM and 50Gb SSD.）
操作系统内核（3.10.0-1160.102.1.el7.x86_64）
操作系统（CentOS:7.9 VM）
平台: x86_64
VM Parameters：除存放和加载镜像日志的参数外，没使用其它参数
2.测试场景
2.1.场景一：Time Of First Operation
2.1.1.问题1：为什么Azul Prime ReadyNow相对于CRaC第二次启动会出现加速幅度降低？
2.2.场景二：Time To Complete 100000 Operations
2.2.1.问题2：为什么Azul Prime ReadyNow相对于CRaC在100000笔请求延迟降低会比CRaC好？
3.补充材料
3.1.CRaC是Azul主导贡献到OpenJDK社区的
常理上讲，Azul Prime ReadyNow作为Azul商业收费版应该比开源CRaC更好。
3.1.1.问题3：Azul Prime ReadyNow的安装包是不是正确的？
3.1.2.问题4：验证所使用的用例是不是正确的？
4.问题分析
4.1.问题1：为什么Azul Prime ReadyNow相对于CRaC第二次启动会出现加速幅度降低？
4.1.1.猜测：串/并行文件处理导致的
4.1.1.1.CRaC用于恢复的文件结构-多文件组成
4.1.1.1.1.第一次启动截图-2.762秒完成启动
4.1.1.1.2.第二次启动截图-进程级恢复（进程ID一致）
4.1.1.2.ReadyNow用于恢复的文件结构-单文件组成
4.1.1.2.1.第一次启动截图-4.678秒完成启动
4.1.1.2.2.第二次启动截图-RootAC(提速16.2%)、APP（提速64.9%）
4.1.1.3.总结
1.单从文件加载效率角度分析，并行文件加载应该比串行文件处理效率高
2.借鉴ReadyNow的方案时，可将用于恢复的文件分割为多文件进行处理，验证是否可进一步优化第二次启动时间？[a.下一步可考虑的工作]
4.2.问题2：为什么Azul Prime ReadyNow相对于CRaC在100000笔请求延迟降低会比CRaC好？
4.2.1.ReadyNow有JVM优化-Falcon JIT Compiler，而CRaC本质上没有优化JVM
4.2.1.1.CRaC-Hotspot VM
CRaC本身没有优化JVM。
4.2.1.2.ReadyNow-Zing VM
将C2替换为Azul自研的Falcon JIT Compiler。
4.2.2.总结
1.可以被Zing VM的Falcon JIT Compiler直接编译的profile是什么？[b.下一步可考虑的工作]
2.可以考虑使用Graal替代Hotspot VM中的C2，验证请求延迟是否会进一步降低？[c.下一步可考虑的工作]