On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <d...@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
