RFR: 8292914: Drop the counter from lambda class names [v6]

[Vojin Jovanovic]

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

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

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`. I would argue that #10024 improves the debugging experience, especially in multi-threaded environments where lambda names can be unstable with the current scheme.

-------------

PR: https://git.openjdk.org/jdk/pull/12579