On Fri, 17 Feb 2023 15:18:25 GMT, Vojin Jovanovic <d...@openjdk.org> wrote:
> We didn't use the cryptographic hash as it is not resilient to the changes > that happen to the bytecode generators of hidden classes. If anything in the > bytecode generation (e.g., in `InnerClassLambdaMetafactory`) changes, the > hashes stored in the metadata files will not be valid anymore. The prime > example of this is the change in the class version between different JDKs. > This makes [reachability > metadata](https://www.graalvm.org/22.2/reference-manual/native-image/metadata/) > useless across different versions of the JDK. This is especially problematic > for cases such as: > > https://github.com/oracle/graalvm-reachability-metadata That's fair, we don't try to retain reachability metadata for lambda (or any other hidden) classes. And we would discard any persistent data (reachability, profiling, etc.) anyway if the class changed, since it is hard to determine whether the change would invalidate whatever data we would retain about that class. > Given lambdas are in almost every stack trace, it is good for debugging that > their names are clearly distinguishable. Adding a stable and unique hash to > the lambda name as in #10024 does that and does not conflict with computing > the cryptographic hash if it is needed by `qbicc`. It seems to me that the hidden class suffix suffices for this as well as anything else, but I might just be strange. 🙂 > I would argue that #10024 improves the debugging experience, especially in > multi-threaded environments where lambda names can be unstable with the > current scheme. I don't think that this change would rule out a change like #10024 (in my mind anyway). But, like I said I think that the problem of hidden classes has to be solved broadly anyway so a change like this at least gets us part of the way there. ------------- PR: https://git.openjdk.org/jdk/pull/12579
