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

This proposal is appealing for its simplicity, however, there are points from [JDK-8292914](https://bugs.openjdk.org/browse/JDK-8292914) that it does not address:
1. *To register lambda classes for serialization*. In this case, the agent run would register all lambdas from the capturing class for serialization: there would be no identifier to distinguish one lambda from another. 
2. *For reproducible builds*. This PR makes a small step towards reproducible builds, however, it complicates the implementation on the Native Image side significantly. Now, as each class needs a unique name, we must create the unique (and stable) lambda-proxy name for all lambdas within a capturing class. This is hard with parallel static analysis as methods are discovered concurrently, and hence non-deterministically. When we discover a class, we would need to find all of its captured lambdas, then perform a deterministic traversal of the class' bytecode in order to give lambda-proxies a stable name. For such an implementation we don't even need this PR as we can simply strip the sequence number from the name and invent a new one. 
3. *To collect profiles of lambda methods for profile-guided optimizations*. With all captured lambdas having the same name, we would get polluted profiles and lose on performance.
4. *To reflectively access lambdas*. Again we would not be able to distinguish between lambdas in the same capturing class and hence we would get imprecise reflection registration.

@dmlloyd Maybe I am missing something, but I don't understand how does this PR make the builds more reproducible?

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

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