Eclipse OpenJ9 中的类共享（5）运行时字节码修改

look_w

运行时字节码修改运行时字节码修改是一种将行为添加到 Java 类中的流行方法。可以使用 JVM 工具接口 (JVMTI)                                        挂钩来执行运行时字节码修改（详细信息可在 找到）。另外，类加载器可以在定义类之前替换类字节。这给类共享带来了额外的挑战，因为一个 JVM                                可能缓存经过修改的字节码，而共享同一个缓存的另一个 JVM 不应加载这些字节码。
但是，由于 OpenJ9 共享类实现的动态性质，采用不同修改类型的多个 JVM                                可以安全地共享同一个缓存。实际上，如果字节码修改的代价高昂，那么对经过修改的类进行缓存有很大的好处，因为只需执行一次转换即可。唯一的要求是，字节码修改应是确定性的且可预测的。修改并缓存一个类之后，就不能再更改它。
可以使用 -Xshareclasses 的 modified=<context>                                子选项共享经过修改的字节码。上下文是一个用户定义的名称，它在共享缓存中创建一个逻辑分区，该 JVM                                加载的所有类都存储在这个分区中。使用这个特定修改的 JVM                                都应使用相同的修改上下文名称，而且它们都将从同一个共享缓存分区中加载类。任何使用同一个共享缓存且未使用                                        modified 子选项的 JVM，都可以按一般方式查找并存储普通的类。
潜在的缺陷如果 JVM 运行着一个已注册的 JVMTI 代理来修改类字节，而且未使用 modified                                子选项，那么仍然可以安全地管理与其他一般 JVM 或与使用其他代理的 JVM                                之间的类共享，但由于要进行额外的检查，会产生一点性能成本。因此，使用 modified                                子选项始终更加高效。
注意，只有使用了 JVMTI API，JVM 才能知道什么时候将进行字节码修改。重新定义和重新转换的类不会存储在缓存中。JVM                                将普通的类字节数据存储在共享缓存中，这允许为从缓存加载的所有类触发 JVMTI                                        ClassFileLoadHook                                事件。因此，如果某个自定义类加载器在定义类之前修改了类字节，而没有使用 JVMTI 和modified 子选项，那么就假设所定义的类是普通类，且其他 JVM 可能无法正确加载它们。
要获得关于对经过修改的字节码进行共享的更多详细信息，请参阅 。