Leyden相关进展
DONE
JEP 483: Ahead-of-Time Class Loading & Linking
JEP 514: Ahead-of-Time Command-Line Ergonomics（暂时用处不大，其实就是把启动）
JEP 515: Ahead-of-Time Method Profiling
Support –add-exports with -XX:+AOTClassLinking
Support –add-opens with -XX:+AOTClassLinking
DOING
Ahead-of-Time Object Caching with Any GC
JEP draft: Ahead-of-Time Code Compilation
核心JEP解读
JEP 483
JEP 483: Ahead-of-Time Class Loading & Linking
存储类加载和链接的训练数据，但当前只支持jdk内置的class loader：System, Extension, & Boot loaders
tips：
对lambda等的优化会比较大
JEP 515
JEP 515: Ahead-of-Time Method Profiling
存储方法的调用数据（方法执行次数等），以便JIT了解方法的执行情况，可以直接进行对应层级的编译优化
tips：
这样做需要注意，由于JIT已知方法的执行情况，理想情况下可以认为热点path代码可以在首次触达时即完成JIT优化，这对CPU资源的开销可能会比较大
也就是说，如果直接接入峰值流量，可能启动初期消耗的CPU资源会较高，可能依然需要慢启动的流程（不过流量放大的速度可以比现在快很多）
未来JEP draft: Ahead-of-Time Code Compilation完成后，上述问题会得到解决
JEP514
JEP 514: Ahead-of-Time Command-Line Ergonomics
作用是把开始训练/生成训练数据的两个命令行合并成一个命令（在应用结束的时候起一个子进程运行生成训练数据的命令）
目前存在一些问题，生成训练数据时候的启动参数是和启动应用时一样的。但在应用容器这样的启动方式时，可能存在像-Dcom.sun.management.jmxremote.port=1099这样的启动参数，会因端口冲突导致生成训练数据的步骤失败。
目前最大的问题
只支持java内置的classloader
BootClassLoader
可能会在未来放开这一限制
Spring所做的jar包展开本质上也是更换了classLoader（非nestedJar的情况下不再需要使用自定义的classLoader）
不支持ZGC
未来会支持
Leyden和Native Image的区别
Leyden相比Native Image而言，不会砍掉JVM的动态性。对开发而言可以做到基本无感。
以下是一些详细说明：
Leyden项目不打算直接合并GraalVM的工作，而是参考一部分Graal思路的同时，在项目开始时保留一部分运行时特征
https://www.infoq.com/news/2022/06/project-leyden-delays-aot/
这种转向在Leyden项目的一部分问答中有所体现
https://mail.openjdk.org/pipermail/discuss/2020-April/005429.html
https://mail.openjdk.org/pipermail/leyden-dev/2022-May/000005.html
官方描述中也可以看出
https://openjdk.org/projects/leyden/notes/01-beginnings
其他
需要关注的工作
jar包展开
https://spring.io/blog/2024/08/29/spring-boot-cds-support-and-project-leyden-anticipation
https://docs.spring.io/spring-boot/reference/packaging/efficient.html